ietf-mxcomp
[Top] [All Lists]

Re: Will Accepting SUBMITTER Get You Blacklisted?

2004-08-09 12:27:42

Graham Murray wrote:

maybe there is room for both. First perform the SPF Mail-From
checks (to verify the mail comes from the sender domain it
claims), so that any subsequent bounces are not sent to
innocent parties

So far I fully agree with you...

only if these pass continue to the 'responsible sender'
checks to ensure that the RFC2822 'sender' is compatible
with the MTA which originated the mail to detect phishing
etc.

...but I don't understand this part.  What do you want to do
if the MAIL FROM test was inconclusive, neither PASS nor FAIL ?

MUAs should display a "PRA" (as specified in core-02 7.5), and
this allows users to detect phishing.  And this feature does
not depend on any 2822 header tests by the MX / MDA, the MUA
can evaluate all corresponding headers:

Resent-Sender / Resent-From / Sender / From in this order, and
if found one address in this header should match the MAIL FROM,
and that's the "PRA".

If there's only a From: header and it doesn't match MAIL FROM,
then treat the MAIL FROM address as "PRA", to be compatible
with 2476 MSAs if they "forgot" to insert a matching Sender.

After this check the MUA has a "PRA" matching the MAIL FROM,
or a dubious mail (e.g. From !~ Sender !~ MAIL FROM !~ From).

If it has a "PRA" it can display it with the SPF result found
in the SPF classic header Received-SPF: (PASS, SOFTFAIL, ERROR,
UNKNOWN, but probably not FAIL, that should be handled before
and never reach a MUA).

So there's only one problem, MUAs must know who generated the
Received-SPF, the phisher or their own mail provider.  But in
theory this could be configured per mail account, when users
enter their mail address / password / host names / etc.

I still don't get the idea why the MX should determine a "PRA",
only the MUA wants to know and display this.  The info passed
from MX to MUA must be in a new header (or in a new parameter
of the Received: header).  No existing MUA knows this new
header / parameter.  Therefore it only works with new MUAs.

If that's the case this new MUA can do the simple "PRA" check,
and display it together with the SPF result found in a new
Received-SPF.  The MX cannot finally judge phishing problems,
it's only a machine.  But the MUA has a human user.

                          Bye, Frank