-----Original Message-----
From: Michael Hammer [mailto:dotzero(_at_)gmail(_dot_)com]
Sent: Thursday, October 28, 2004 1:27 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
On Thu, 28 Oct 2004 11:43:14 -0400, Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
On Thu, 2004-10-28 at 10:36, Michael Hammer wrote:
I guess I'm going to have to disagree with Meng and his belief
that
there isn't a problem with applying (and evangelizing that this is
ok)
PRA to SPF1 records.
Here is a link to a page on pobox holding up examples of how to do
things properly if you are a web generated emailer:
http://spf.pobox.com/webgenerated.html
Applying PRA to either of these approaches should cause mail to be
rejected by the recipient MTA if the domain of the true sender has
published an SPF1 record that makes any sense at all for
protecting
the return path.
How so? PRA would end up using Sender header in the "This is better"
example, therefore it would check a record in egreetings.com DNS.
PRA
would end up using From header in "This works too" case and
therefore
use evite.com DNS.
Just a note on the advice at spf.pobox.com. The advice given at the
above location is a little inconsistent with this statement
"Strictly speaking, Sender ID requires only that the Purported
Responsible Address match the sending client's IP. If the client really
wants their main domain name to appear in the "From" header, you can put
your domain into the "Sender" field. But this is not recommended because
there may be some people out there who test only the "From:" header and
require an SPF pass on that.
"
from http://spf.pobox.com/esps.html
If one were to take the cumulative advice of these two pages they would
have no choice but to come away thinking they were being presented with
a "pick your poison" decision where they would have to expect random and
sometimes not really resolvable failures.
If this is really the case then PRA would do nothing to stop phishing
nor would it protect the 2822 From:
Yes, but this is indeed true based on the published PRA algorithm. This
exact point was one of the more common complaints about SenderID in the
MARID discussions. The PRA protects whichever header is the one that
comes out of the PRA algorithm.
Consider that in the first example the 2822 From: is
user(_at_)example(_dot_)com(_dot_)
If example.com publishes an SPF record and From: doesn't match then I
would expect a fail. To accept the mail on a pass from sender but a
fail for From: means that anyone can spoof the from with only trivial
effort.
So we have:
HELO (for arguments sake) PASS
Mail From: PASS
Sender: PASS
From: FAIL
How does this protect RFC2822 From: with regard to phishing if you
accept a From: where the owner of the domain has published which hosts
you can expect mail from that domain to originate from? It doesn't.
The alternative, which is what I would expect, is for mail from 3rd
parties (web to mail) which meets the requirements of SPF1 (Classic)
to be rejected because of the failed PRA check on From:.
I sent a card through egreetings from myself (dotzero(_at_)gmail(_dot_)com) to
myself to show the headers. Guess what, gmail gave a nice big yellow
warning that it might be forged. At first I thought they were doing
PRA type checks but it turns out they are only checking (and warning)
if the From: is from user(_at_)gmail(_dot_)com
This does show why PRA checks against SPF1 records can cause problems.
I'll have to go back and re-examine the second example in more detail
at a later point. I have some production issues I have to work on.
What do you mean by "true sender"? If you mean the person causing
the
invitations to go out, "user(_at_)example(_dot_)com", none of the
return-path
values have example.com as a domain. example.com's SPF records would
never be checked.
PRA protects the RFC2822 From: which in this case is
user(_at_)example(_dot_)com(_dot_)
SPF was initially intended to protect the RFC2821 Mail From.
Retrofitting may solve political issues but it generates new technical
ones. As I posted in the past, the correct solution would have been to
add the scopes in a new version to avoid conflicts or
misunderstandings.
Mike
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?listname=spf-
discuss(_at_)v2(_dot_)listbox(_dot_)com