On Aug 17, 2004, at 11:11 AM, Meng Weng Wong wrote:
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.
I think Meng has highlighted an incredibly important practical issue
with PRA and marid-core as presently defined. I have recently been
struggling to determine the ultimate utility of MARID to the service
provider, without much to show for it. Consider the following
postulate:
A policy for authorizing a given message to be transported by a given
agent cannot be sufficiently expressed by a single domain in many
cases. The PRA "algorithm" is a means to derive a single pointer to an
expression of policy. As such, the chances that a receiver can
conclude an explicit permit/deny result is greatly diminished (i.e. the
only potentially conclusive, explicit result is that the PRA points to
an explicit deny policy).
By considering and respecting the policies of both (or perhaps even
all) domains purporting to be senders, one could apply logical
equations to yield greater conclusive results (e.g. the table I provide
below for applying policies to the 2821 and 2822 From domains).
2821 2822
MAIL FROM From:
- - = Don't accept.
+ - = Don't accept.
- + = Don't accept.
- ?~ = Don't accept.
?~ - = Don't accept.
?~ ?~ = Inconclusive.
+ ?~ = Inconclusive.
?~ + = Inconclusive.
+ + = Accept.
This could be extended to consider the policies of Sender, Resent-From,
or any other purported senders.
Tripp