Mailing List Archive

Paul D.Smith wrote on 2009-07-07:

> I want to be able to send from account "myself@hotmail.com" whilst
> pretending to be sending from "me@myself.com". Can SPF records handle
this
> without allowing <anyone>@hotmail.com to also send as if
"me@myself.com"?

No. You can use "?" in the SPF record for myself.com (which
doesn't exist by the way) as in "... ?include:___" to include whatever
HotMail tells you to list for their mail servers. That will tell
everyone to treat mail from HotMail servers as Neutral.

I've not worked much with macros but the "sender" would likely
be your e-mail address...otherwise HotMail's SPF (well, Sender ID)
record would apply.

-----
SPF FAQ: http://www.openspf.org/FAQ
Common mistakes: http://www.openspf.org/FAQ/Common_mistakes

- Steve Yates
- ITS, Inc.
- Error: Sector not found. Search behind couch? (Y/N)

~ Taglines by Taglinator: www.srtware.com ~


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Steve,

Thanks for that. I was thinking about this more last night and I think, at
least for what I want, SPF records don't work and severely limit how I
currently work - In fact the make is IMPOSSIBLE. Perhaps an example might
be in order? Hopefully someone will read this and be able to explain how I
can make it work!

I represent a small organisation and as part of our webhost package, we are
supplied with e-mail redirection so....

Any e-mail to "paul@organisation.org" gets forwarded to (say)
"paulshotmail@hotmail.com". I can control where the e-mail goes, but that's
it.

Now our package does NOT include access to an SMTP server, and in any case
my employers block POP3 and SMTP access so I could not access such a server
from work anyway. Since I often have to deal with problems in my lunchhour,
I do need to be able to send e-mails from work.

Before SPF records, I happily used a Hotmail account and Windows Live.
Windows Live uses WebDav (or similar) and works from my work PC and I can
configure my Hotmail to send as it the e-mail came from
"paul@organisation.org".

The problem is that I only seem to be able to use SPF records to allow
ANYONE using a Hotmail account to send on behalf of paul@organisation.org.
"This is totally bogus man" because paul@organisation.org is a web-visible
address and any SPAMmer with half a brain will check the SPF records for
organisation.org and figure out they can use Hotmail to SPAM out pretending
to be me.

It seems that SPF records are simply a curse for me and have completely cut
me off from the e-mail world and there is absolutely nothing I can do about
it.

So, anyone got a bright idea? At present SPF records simply look like
another failed attempt at anti-SPAM to me because they only work if the
"alternate domain" is very small and very tightly controlled. I would
submit that that is rarely the case.

Paul DS

--------------------------------------------------
From: "Steve Yates" <steve@teamITS.com>
Sent: Tuesday, July 07, 2009 5:24 PM
To: <spf-help@v2.listbox.com>
Subject: RE: [spf-help] SPF and usernames

> Paul D.Smith wrote on 2009-07-07:
>
>> I want to be able to send from account "myself@hotmail.com" whilst
>> pretending to be sending from "me@myself.com". Can SPF records handle
> this
>> without allowing <anyone>@hotmail.com to also send as if
> "me@myself.com"?
>
> No. You can use "?" in the SPF record for myself.com (which
> doesn't exist by the way) as in "... ?include:___" to include whatever
> HotMail tells you to list for their mail servers. That will tell
> everyone to treat mail from HotMail servers as Neutral.
>
> I've not worked much with macros but the "sender" would likely
> be your e-mail address...otherwise HotMail's SPF (well, Sender ID)
> record would apply.
>
> -----
> SPF FAQ: http://www.openspf.org/FAQ
> Common mistakes: http://www.openspf.org/FAQ/Common_mistakes
>
> - Steve Yates
> - ITS, Inc.
> - Error: Sector not found. Search behind couch? (Y/N)
>
> ~ Taglines by Taglinator: www.srtware.com ~
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/
> Powered by Listbox: http://www.listbox.com
>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

> Thanks for that. I was thinking about this more last night and I think,
> at
> least for what I want, SPF records don't work

SPF records *do* work. They just take a little thinking about when you
want to do the opposite of what they're designed for.

> Any e-mail to "paul@organisation.org" gets forwarded to (say)
> "paulshotmail@hotmail.com". I can control where the e-mail goes, but
> that's it.

First off, you'll find you get a much higher standard of assistance if you
refrain from telling us porkies. My money's on you not owning
organisation.org.

> The problem is that I only seem to be able to use SPF records to allow
> ANYONE using a Hotmail account to send on behalf of paul@organisation.org.
> "This is totally bogus man" because paul@organisation.org is a web-visible
> address and any SPAMmer with half a brain will check the SPF records for
> organisation.org and figure out they can use Hotmail to SPAM out
> pretending to be me.

Had you read the mail to which you replied, you'd see that this is not the
case; SPF record clauses can have positive, negative, neutral, or
uncertain qualifiers. Since what you want is for Hotmail's servers to be
seen neither as positive nor as negative, one of the latter two types
would seem appropriate.

> It seems that SPF records are simply a curse for me and have completely
> cut
> me off from the e-mail world and there is absolutely nothing I can do
> about it.

That's incorrect.

> So, anyone got a bright idea? At present SPF records simply look like
> another failed attempt at anti-SPAM to me

And this is at the root of your problems: SPF is *not* an anti-spam
measure, it's an anti-forgery measure.

> because they only work if the
> "alternate domain" is very small and very tightly controlled.

This is incorrect too.

> I would submit that that is rarely the case.

I would submit that fixing your issue is relatively straightforward, but
will not be effected by throwing your toys out of the pram.

Vic.



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Vic,

Comments below. I can only assume I'm missing some key element of SPF at
present because I can't see how SPF is a powerful solution to a problem.
Perhaps my comments and questions below will help us get to a common
understanding. Look for [PDS].

Paul DS

--------------------------------------------------
From: "Vic" <spf1@beer.org.uk>
Sent: Wednesday, July 08, 2009 8:24 AM
To: <spf-help@v2.listbox.com>
Subject: Re: [spf-help] SPF and usernames

>
>> Thanks for that. I was thinking about this more last night and I think,
>> at
>> least for what I want, SPF records don't work
>
> SPF records *do* work. They just take a little thinking about when you
> want to do the opposite of what they're designed for.
>
>> Any e-mail to "paul@organisation.org" gets forwarded to (say)
>> "paulshotmail@hotmail.com". I can control where the e-mail goes, but
>> that's it.
>
> First off, you'll find you get a much higher standard of assistance if you
> refrain from telling us porkies. My money's on you not owning
> organisation.org.
>

[PDS] Since SPF records are open, the domain is "enfieldlibdems.org.uk", not
that this information should have any bearing on the question whatsoever as
the logic and requirements are the same.

>> The problem is that I only seem to be able to use SPF records to allow
>> ANYONE using a Hotmail account to send on behalf of
>> paul@organisation.org.
>> "This is totally bogus man" because paul@organisation.org is a
>> web-visible
>> address and any SPAMmer with half a brain will check the SPF records for
>> organisation.org and figure out they can use Hotmail to SPAM out
>> pretending to be me.
>
> Had you read the mail to which you replied, you'd see that this is not the
> case; SPF record clauses can have positive, negative, neutral, or
> uncertain qualifiers. Since what you want is for Hotmail's servers to be
> seen neither as positive nor as negative, one of the latter two types
> would seem appropriate.
>

[PDS] So the SPF solution to my problem is to render SPF completely
meaningless? Doesn't "neutral" or "uncertain" merely push the problem of
deciding "should I accept this e-mail" back on the recipient, which would
have been the case were there no such thing as SPF?

>> It seems that SPF records are simply a curse for me and have completely
>> cut
>> me off from the e-mail world and there is absolutely nothing I can do
>> about it.
>
> That's incorrect.
>
>> So, anyone got a bright idea? At present SPF records simply look like
>> another failed attempt at anti-SPAM to me
>
> And this is at the root of your problems: SPF is *not* an anti-spam
> measure, it's an anti-forgery measure.
>

[PDS] I fail to see such a clear distinction between SPAM and forgery. In
almost all SPAM e-mail whichi I receive, the sender and from addresses are
also forged and SPAM and forgery are one and the same for me.

[PDS] There is a technical split in that I might decide to send a single
e-mail pretending to be you and this would be forgery but not, perhaps,
SPAM, but I still don't understand how SPF is a good solution to this. If I
really care if it's you, or not, I would use public/private keys to confirm
the senders identity which seems to be a much stronger check of your
identify.

>> because they only work if the
>> "alternate domain" is very small and very tightly controlled.
>
> This is incorrect too.

[PDS] Please provide a counter example because I'm afraid I just don't see
it. Perhaps I've misunderstood what SPF does because I think it says "this
e-mail originated from domain X.com but claimed to be sent on behalf of
someone in Y.com; Y.com has said this is OK". Now unless the users of Y.com
can restrict who sends from X.com, the opportunity for forgery remains.

>
>> I would submit that that is rarely the case.
>
> I would submit that fixing your issue is relatively straightforward, but
> will not be effected by throwing your toys out of the pram.
>

[PDS] As I said above, perhaps you can provide me with an example please
than indicates why SPF is so powerful because at present I just don't see
it.

> Vic.





-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Paul D.Smith wrote:
> [PDS] Please provide a counter example because I'm afraid I just don't
> see it. Perhaps I've misunderstood what SPF does because I think it
> says "this e-mail originated from domain X.com but claimed to be sent on
> behalf of someone in Y.com; Y.com has said this is OK". Now unless the
> users of Y.com can restrict who sends from X.com, the opportunity for
> forgery remains.

SPF doesn't say that. Please take a minute to review how email works:
First of all there is a transport, featuring one sender and one or
more recipients. You have no message yet, neither headers nor body.
SPF works here. Secondly, you have a message with a bunch of headers,
including a "From:" one. Upon reception, the transport envelope sender
address is copied into the "Return-Path:" message header.

The /on behalf/ wording originates from difference between the "From:"
and the envelope sender.

SPF only sees one address: the envelope sender, a.k.a Return-Path,
a.k.a mailfrom. Its purpose is to check if the mail domain used in
that address authorizes the IP address to use its name.

HTH



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

On Wed, Jul 8, 2009 at 12:02, Alessandro Vesely<vesely@tana.it> wrote:
> Paul D.Smith wrote:
>>
>> [PDS] Please provide a counter example because I'm afraid I just don't see
>> it.  Perhaps I've misunderstood what SPF does because I think it says "this
>> e-mail originated from domain X.com but claimed to be sent on behalf of
>> someone in Y.com; Y.com has said this is OK".  Now unless the users of Y.com
>> can restrict who sends from X.com, the opportunity for forgery remains.
>
> SPF doesn't say that. Please take a minute to review how email works: First
> of all there is a transport, featuring one sender and one or more
> recipients. You have no message yet, neither headers nor body. SPF works
> here. Secondly, you have a message with a bunch of headers, including a
> "From:" one. Upon reception, the transport envelope sender address is copied
> into the "Return-Path:" message header.
>
> The /on behalf/ wording originates from difference between the "From:" and
> the envelope sender.
>
> SPF only sees one address: the envelope sender, a.k.a Return-Path, a.k.a
> mailfrom. Its purpose is to check if the mail domain used in that address
> authorizes the IP address to use its name.

And, by extension, if you want to provide complete coverage to stop
people being able to forge email from your domain, you need to use
something like DKIM too.

It is trivial to send an email with mail headers that appear to come
from one domain, but with an envelope sender of a completely different
one. The one the end user sees in their mail client is the one in the
mail headers. If you want to avoid forgery you need to protect both.

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Alessandro,

Let me see if I understand what you are telling me. I believe the examples
below tie in with what you are saying, and although perhaps my explanation
was not couched in terms that you recognised, I don't think it changes my
arguments. However have a look please and tell me whether I'm still missing
something.

Thanks,
Paul DS

A sending MTA connects to a receiving MTA (from a remote IP address). The
receiver receives a "HELO" which identifies a domain (supposedly the one of
the sending MTA); check one is that the HELO domain specified matches the
remote IP address. Of course this check is possible without SPF records but
SPF records can be more rigourous and can limit the IP addresses that might
be returned from a straight A or AAAA record look-up. In the example I gave
(sending from a Hotmail account, pretending to be from other domain) this
test would presumably pass because it is a real Hotmail server connecting to
the recipients MTA.

Next is the checking of the MAIL FROM. Now this does not indicate the
Hotmail domain so the SPF look-up for the MAIL FROM domain does not return a
valid Hotmail IP address and this would result in my mail being rejected.

Now at this point, how could I ensure my mail gets through?

1. I could have an "allow all" SPF record for my domain - very bad, well in
fact exactly as pre-SPF.

2. I could add all the IP addresses for Hotmail to my SPF records for my
real domain. But then anyone with a Hotmail account can spoof me sending
from my domain - still not good and providing little protection for the
recipient or for me as being anti-forged.

3. I can similar to #2 except I put "hotmail.com" servers into the SPF
records such that my domain opens up Hotmail.com senders but without the
need for me to explicitly add IP addresses - still not good. This is why I
was giving the Y.com/X.com example - I would be allowing
<anyone>@hotmail.com to send as my@mydomain.com whereas in fact I only want
to allow me-hotmail@hotmail.com to be able to do this.

At this point I can't do anything more because SPF is unable to get access
to "me-hotmail@hotmail.com" and therefore cannot perform "true sender"
checking (in fact this information is present in a Hotmail X-header - but
let's not go there).

So, I seem to be able to only do the following...

- Allow anyone to forge me
- Allow nobody to forge me (where I might legitimately want to forge myself)
- Allow anyone on an entire specified domain to forge me.

The last one is fine if I can be sure that the specified domain is tightly
controlled (for example my employers would jump all over someone
illegitimately forging from their work accounts) but it doesn't work for
domains such as Hotmail where a forger can create and use an account to
forge e-mails and then vanish.

--------------------------------------------------
From: "Alessandro Vesely" <vesely@tana.it>
Sent: Wednesday, July 08, 2009 12:02 PM
To: <spf-help@v2.listbox.com>
Subject: Re: [spf-help] SPF and usernames

> Paul D.Smith wrote:
>> [PDS] Please provide a counter example because I'm afraid I just don't
>> see it. Perhaps I've misunderstood what SPF does because I think it says
>> "this e-mail originated from domain X.com but claimed to be sent on
>> behalf of someone in Y.com; Y.com has said this is OK". Now unless the
>> users of Y.com can restrict who sends from X.com, the opportunity for
>> forgery remains.
>
> SPF doesn't say that. Please take a minute to review how email works:
> First of all there is a transport, featuring one sender and one or more
> recipients. You have no message yet, neither headers nor body. SPF works
> here. Secondly, you have a message with a bunch of headers, including a
> "From:" one. Upon reception, the transport envelope sender address is
> copied into the "Return-Path:" message header.
>
> The /on behalf/ wording originates from difference between the "From:" and
> the envelope sender.
>
> SPF only sees one address: the envelope sender, a.k.a Return-Path, a.k.a
> mailfrom. Its purpose is to check if the mail domain used in that address
> authorizes the IP address to use its name.
>
> HTH
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
> Archives: https://www.listbox.com/member/archive/1020/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/1020/
> Powered by Listbox: http://www.listbox.com
>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

On Wed, Jul 8, 2009 at 12:53, Paul D.Smith<paul_d_smith@hotmail.com> wrote:
> A sending MTA connects to a receiving MTA (from a remote IP address).  The
> receiver receives a "HELO" which identifies a domain (supposedly the one of
> the sending MTA);

It identifies the hostname of the sending MTA.

> check one is that the HELO domain specified matches the
> remote IP address.

This is not mandated by any RFC I'm aware of (though it is good
practice). The only RFC requirement is that it is a correctly
formatted hostname, including domain (eg host.example.com).

> Of course this check is possible without SPF records but
> SPF records can be more rigourous and can limit the IP addresses that might
> be returned from a straight A or AAAA record look-up.  In the example I gave
> (sending from a Hotmail account, pretending to be from other domain) this
> test would presumably pass because it is a real Hotmail server connecting to
> the recipients MTA.

Note that the check is that the connecting server is authorized to use
the name in the HELO string.

> Next is the checking of the MAIL FROM.  Now this does not indicate the
> Hotmail domain so the SPF look-up for the MAIL FROM domain does not return a
> valid Hotmail IP address and this would result in my mail being rejected.

No, the Mail From is checked against the domain provided in the Mail
From. If you are sending from your own domain then it will be your
domain's SPF record that is checked.

> Now at this point, how could I ensure my mail gets through?
>
> 1. I could have an "allow all" SPF record for my domain - very bad, well in
> fact exactly as pre-SPF.

Correct.

> 2. I could add all the IP addresses for Hotmail to my SPF records for my
> real domain.  But then anyone with a Hotmail account can spoof me sending
> from my domain - still not good and providing little protection for the
> recipient or for me as being anti-forged.

Correct.

> 3. I can similar to #2 except I put "hotmail.com" servers into the SPF
> records such that my domain opens up Hotmail.com senders but without the
> need for me to explicitly add IP addresses - still not good.

Correct - and indeed it's identical to (2).

> This is why I
> was giving the Y.com/X.com example - I would be allowing
> <anyone>@hotmail.com to send as my@mydomain.com whereas in fact I only want
> to allow me-hotmail@hotmail.com to be able to do this.

No, you'll be allowing anybody who is allowed to send email through
Hotmail's servers to send email from your domain and pass the SPF
checks. Remember, that's the point of the SPF record, it identifies
which hosts are allowed to send email on behalf of a domain.

> At this point I can't do anything more because SPF is unable to get access
> to "me-hotmail@hotmail.com" and therefore cannot perform "true sender"
> checking (in fact this information is present in a Hotmail X-header - but
> let's not go there).

Correct - however it is important to note that:

a) SPF was never designed with this in mind - it is intended to
protect domains, not individual accounts
b) At no point is there any way for anything outside of Hotmail to
know anything about the Hotmail account that's linked to your own
domain

Also, it's important to note that Hotmail uses Sender-ID, not SPF.
The 2 are similar, but not the same.

> So, I seem to be able to only do the following...
>
> - Allow anyone to forge me
> - Allow nobody to forge me (where I might legitimately want to forge myself)
> - Allow anyone on an entire specified domain to forge me.

Assuming you only use SPF, yes. However as stated in the SPF FAQ, it
isn't intended to be a complete solution to the problem of mail
forgery, it is intended to only protect one part of the problem.

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

"Paul D.Smith" <paul_d_smith@hotmail.com> wrote:
...
> 2. I could add all the IP addresses for Hotmail to my SPF records for my
> real domain. But then anyone with a Hotmail account can spoof me sending
> from my domain - still not good and providing little protection for the
> recipient or for me as being anti-forged.
>
> 3. I can similar to #2 except I put "hotmail.com" servers into the SPF
> records such that my domain opens up Hotmail.com senders but without the
> need for me to explicitly add IP addresses - still not good. This is why
> I
> was giving the Y.com/X.com example - I would be allowing
> <anyone>@hotmail.com to send as my@mydomain.com whereas in fact I only
> want
> to allow me-hotmail@hotmail.com to be able to do this.
>
> At this point I can't do anything more because SPF is unable to get access
> to "me-hotmail@hotmail.com" and therefore cannot perform "true sender"
> checking (in fact this information is present in a Hotmail X-header - but
> let's not go there).
>
> So, I seem to be able to only do the following...
>
> - Allow anyone to forge me
> - Allow nobody to forge me (where I might legitimately want to forge
> myself)
> - Allow anyone on an entire specified domain to forge me.
>
> The last one is fine if I can be sure that the specified domain is tightly
> controlled (for example my employers would jump all over someone
> illegitimately forging from their work accounts) but it doesn't work for
> domains such as Hotmail where a forger can create and use an account to
> forge e-mails and then vanish.

This is correct. This is a known limitation of SPF and is described in
paragraph 10.4 (part of security considerations) of RFC 4408:

http://www.openspf.org/RFC_4408#cross-user-forgery

In your case limiting forgery opportunities to Hotmail users is
significant progress compared to the pre-SPF case of everyone on the
Internet.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Rob,

Thanks for the response - very clear. A few comments in-line below marked
[PDS].

Paul DS.

>> Next is the checking of the MAIL FROM. Now this does not indicate the
>> Hotmail domain so the SPF look-up for the MAIL FROM domain does not
>> return a
>> valid Hotmail IP address and this would result in my mail being rejected.
>
> No, the Mail From is checked against the domain provided in the Mail
> From. If you are sending from your own domain then it will be your
> domain's SPF record that is checked.

[PDS] Whoa, where does the value of the address in "MAIL FROM" come from
then? As an example, most e-mail packages I've seen (I use Windows Live to
type this) allow two fields to be specified, named "e-mail address" and
"reply address" or similar. Normally I would set these to be the same but
then that doesn't seem to make sense to me because MAIL FROM and "From
header" would be the same and then I can't see how there is a problem?

>> Now at this point, how could I ensure my mail gets through?
>>
>> 1. I could have an "allow all" SPF record for my domain - very bad, well
>> in
>> fact exactly as pre-SPF.
>
> Correct.
>
>> 2. I could add all the IP addresses for Hotmail to my SPF records for my
>> real domain. But then anyone with a Hotmail account can spoof me sending
>> from my domain - still not good and providing little protection for the
>> recipient or for me as being anti-forged.
>
> Correct.
>
>> 3. I can similar to #2 except I put "hotmail.com" servers into the SPF
>> records such that my domain opens up Hotmail.com senders but without the
>> need for me to explicitly add IP addresses - still not good.
>
> Correct - and indeed it's identical to (2).
>
>> This is why I
>> was giving the Y.com/X.com example - I would be allowing
>> <anyone>@hotmail.com to send as my@mydomain.com whereas in fact I only
>> want
>> to allow me-hotmail@hotmail.com to be able to do this.
>
> No, you'll be allowing anybody who is allowed to send email through
> Hotmail's servers to send email from your domain and pass the SPF
> checks. Remember, that's the point of the SPF record, it identifies
> which hosts are allowed to send email on behalf of a domain.

[PDS] We may be saying the same thing here in two different ways. Are you
saying that for example "noddy@hotmail.com" could send an e-mail which would
reach you and look as if it were sent from mydomain.com? Or are you saying
that somehow I have allowed the user whose address is noddy@hotmail.com to
use mydomain.com's servers to send an e-mail that appears to have come from
Hotmail servers?

>
>> At this point I can't do anything more because SPF is unable to get
>> access
>> to "me-hotmail@hotmail.com" and therefore cannot perform "true sender"
>> checking (in fact this information is present in a Hotmail X-header - but
>> let's not go there).
>
> Correct - however it is important to note that:
>
> a) SPF was never designed with this in mind - it is intended to
> protect domains, not individual accounts
> b) At no point is there any way for anything outside of Hotmail to
> know anything about the Hotmail account that's linked to your own
> domain
>
> Also, it's important to note that Hotmail uses Sender-ID, not SPF.
> The 2 are similar, but not the same.
>
>> So, I seem to be able to only do the following...
>>
>> - Allow anyone to forge me
>> - Allow nobody to forge me (where I might legitimately want to forge
>> myself)
>> - Allow anyone on an entire specified domain to forge me.
>
> Assuming you only use SPF, yes. However as stated in the SPF FAQ, it
> isn't intended to be a complete solution to the problem of mail
> forgery, it is intended to only protect one part of the problem.

[PDS] The follownig may be wrong depending on answers to my comments above.
OK, options 1 and 3 I understand but option 2 looks like a very small case.
Who realisticly controls a second domain so tightly as to be happy to enable
it to send on behalf of their first domain? Surely the second domain being
"open" like Hotmail is a much more common occurence?



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

Paul D.Smith wrote:
> [PDS] Whoa, where does the value of the address in "MAIL FROM" come from
> then? As an example, most e-mail packages I've seen (I use Windows Live
> to type this) allow two fields to be specified, named "e-mail address"
> and "reply address" or similar. Normally I would set these to be the
> same but then that doesn't seem to make sense to me because MAIL FROM
> and "From header" would be the same and then I can't see how there is a
> problem?

The Reply-To header is not the "MAIL FROM". (Use the former if you
answer to a message that has been forwarded to you, and you want
replies to follow the same path rather than get back to you directly.)

When you send from hotmail, the "MAIL FROM" is set to your hotmail
account. Thus any recipient carrying out SPF checks will only consider
hotmail's SPF record, and get a "pass" result. SPF-checking the From
header is not recommended by any standard. Some MTA software can do
it, if configured for that, but I don't think it would better a
message's spam score after "MAIL FROM" already gave a "pass".

>> No, you'll be allowing anybody who is allowed to send email through
>> Hotmail's servers to send email from your domain and pass the SPF
>> checks. Remember, that's the point of the SPF record, it identifies
>> which hosts are allowed to send email on behalf of a domain.
>
> [PDS] We may be saying the same thing here in two different ways. Are
> you saying that for example "noddy@hotmail.com" could send an e-mail
> which would reach you and look as if it were sent from mydomain.com?

Regular hotmail users are not allowed to use _whatever_ "From"
address, they can only use verified addresses. Hence, noddy in the
example above is someone of hotmail staff, an intruder, or both. If
your domain's SPF record includes the spf-X.hotmail.com (X=a,b,c,d) or
anything to that effect (#2), then that message will pass SPF checks.

> Or are you saying that somehow I have allowed the user whose address is
> noddy@hotmail.com to use mydomain.com's servers to send an e-mail that
> appears to have come from Hotmail servers?

You cannot send messages using a "MAIL FROM:<whatever@hotmail.com>"
from your servers and get a pass, unless your servers are authorized
by hotmail.com's SPF record.



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

At 09:04 AM 7/8/2009, you wrote:
> SPF-checking the From header is not recommended by any standard. Some MTA software can do it, if configured for that, but I don't think it would better a message's spam score after "MAIL FROM" already gave a "pass".

Presumably you meant SPF Checking the REPLY TO header is not recommended ??


-john

On Wed, Jul 8, 2009 at 14:04, Paul D.Smith<paul_d_smith@hotmail.com> wrote:
>
> [PDS] Whoa, where does the value of the address in "MAIL FROM" come from
> then?

"That depends"

In theory, it will be the same as the "From:" line in the mail header,
but there is nothing to enforce that. Much like "BCC:" is a fiction
created by your mail client ;)

> As an example, most e-mail packages I've seen (I use Windows Live to
> type this) allow two fields to be specified, named "e-mail address" and
> "reply address" or similar.  Normally I would set these to be the same but
> then that doesn't seem to make sense to me because MAIL FROM and "From
> header" would be the same and then I can't see how there is a problem?

When a mail is sent the MAIL FROM and RCPT TO values are passed
between the servers, then the email is passed as DATA, including all
the headers your mail client sees. There is nothing that enforces the
MAIL FROM and RCPT TO values matching anything in the DATA section.

> [PDS] We may be saying the same thing here in two different ways.  Are you
> saying that for example "noddy@hotmail.com" could send an e-mail which would
> reach you and look as if it were sent from mydomain.com?  Or are you saying
> that somehow I have allowed the user whose address is noddy@hotmail.com to
> use mydomain.com's servers to send an e-mail that appears to have come from
> Hotmail servers?

What I'm saying is that however you authorise servers, whether it's by
IP or hostname, makes no difference. That you've authorised the
servers is all that matters. You're not authorising the users, you're
authorising the servers.

> [PDS] The follownig may be wrong depending on answers to my comments above.
> OK, options 1 and 3 I understand but option 2 looks like a very small case.
> Who realisticly controls a second domain so tightly as to be happy to enable
> it to send on behalf of their first domain?  Surely the second domain being
> "open" like Hotmail is a much more common occurence?

I could give you a long list ;) There are many people who authorise
servers run by other people to send on their behalf and expect those
servers to be (relatively) tightly controlled. For people that
entirely outsource their email, as you have done, the situation you
describe is normal, and there's nothing you can do about it.

--
Please keep list traffic on the list.

Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com

John Blazek wrote:
> At 09:04 AM 7/8/2009, you wrote:
>> SPF-checking the From header is not recommended by any standard. Some MTA software can do it, if configured for that, but I don't think it would better a message's spam score after "MAIL FROM" already gave a "pass".
>
> Presumably you meant SPF Checking the REPLY TO header is not recommended ??

I've never seen checking the reply-to.

Checking From may make sense sometimes, e.g. in case an spf record is
missing for the helo name and the MAIL FROM is blank. Courier-MTA, for
one, can do that; it has a mailfromok configuration parameter to
explicitly skip checking From in case the MAIL FROM already succeeded.



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1020/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1020/
Powered by Listbox: http://www.listbox.com