----- Original Message -----
From: "Michael Hammer" <dotzero(_at_)gmail(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, October 28, 2004 3:26 PM
Subject: Re: [spf-discuss] Summary Please - where is SPF 1?
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.
Good point Michael.
Now lets consider real "situations!"
The 2821.MailFrom: passes and even matches the 2822.From!! The domains are
ROCK SPF/PRA solid!
The user gets the mail and sees he wants to reply for one reason or another.
The 2822.Reply-To: POINTS TO A DIFFERENT ADDRESS and is a spoofed or not
correct.
His MUA is "trained" to automatically used the 2822.Reply-To so thats a
problem.
But lets imagine the user is smarter than most and will look at message
properties or simply "Reply To All" to get the From: address to reply!
The From: address domain is SPF solid, but the user part is SPOOF or
non-existence!
In reality, there is:
The Sender Address 2821.MailFrom
The Display Address: 2822.From:
The Reply Address: 2822.Reply-To: | 2822.From
So like I said many times, until the transaction itself it AUTHENTICATED and
VALIDATED from a SMTP compliancy standpoint, none of the proposals will
fully work well at all. In our work, SPF is working to protect local
domains, For external domains, its nothing but wasted overhead and you
can't trust the results. So we use a CBV to reject the spoofing to a very
high degree.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office