On Tue, Aug 17, 2004 at 08:03:25AM -0700, Rand Wacker wrote:
| On Tue, 17 Aug 2004, Meng Weng Wong wrote:
|
| > I personally think that if the PRA lookup returns "none" or
| > "unknown", MAIL FROM should be checked, and if that test
| > returns "fail" then the message should be rejected.
|
| You mean if the message has *no* From, Sender, Resent-From, or
| Resent-Sender headers, or if there is no SUBMITTER argument?
|
I mean:
MAIL FROM:<bounces(_at_)citibank(_dot_)com>
Resent-From: <noSPFrecord(_at_)clueless(_dot_)com>
From: <service(_at_)citibank(_dot_)com>
Given that clueless.com does not publish an SPF record, an
MTA operating solely on a PRA algorithm will let the message
through because the result of the PRA evaluation is "none".
Given that the installed base of MUAs cannot be expected to
display "Allegedly from service(_at_)citibank(_dot_)com via
noSPFrecord(_at_)clueless(_dot_)com", for the next few years the
average user will see in their MUA only
From: <service(_at_)citibank(_dot_)com>
If an MTA were allowed to do SPF checks on the MAIL FROM
when the spf/PRA result is "none" or "unknown", this
scenario would be defeated. Upgrading MTAs is quicker than
upgrading MUAs.
That shifts the spammer position to:
MAIL FROM:<noSPFrecord(_at_)clueless(_dot_)com>
Resent-From: <noSPFrecord(_at_)clueless(_dot_)com>
From: <service(_at_)citibank(_dot_)com>
That is a small but significant improvement:
1) it tells clueless.com that they need to set up SPF records
2) it keeps the existing SPF Classic userbase happy, and
removes the need for a dual-standard deployment plan.