On Aug 17, 2004, at 11:11 AM, Meng Weng Wong wrote:
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.
So this has nothing to do with the presence or absence of the SUBMITTER
parameter, but rather with the presence of a SPF v2/PRA record for the
PRA domain.
I'm in favor - unless I'm missing something it doesn't diminish the
PRA, getting rid of dual standards is a good thing, and more net
happiness in the world is also a good thing :-).
Margaret.