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.
If this is really the case then PRA would do nothing to stop phishing
nor would it protect the 2822 From:
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