Charles Lindsey wrote:
Actually, the best suggestion I have seen is that POP3/IMAP servers should
see to the matter. I realise that might not be easy for POP3, but IMAP is
already so bloated with extensions that another one would hardly be
noticed :-( .
Yes, I also shuddered slightly when I suggested it. But it seemed to fit
the most with what was going on. IMAP/POP servers are what the MUA is
talking with; they *are* the representative for the MDA; and the MUA is
*already* talking with the IMAP/POP servers, so could easily ask for a
bit more information.
We can write it up and see if it flies. Here's how it could look:
IMAP
x CAPABILITY
x CAPABILITY Authentication-Results=isp.example.net
x OK CAPABILITY completed
POP3
CAPA
Authentication-Results=isp.example.net
In both cases, the isp.example.net is the authserv-id put in by *this*
MDA system.
A coworker also suggested the following: If you trust that your MTAs from
the border inbound are compliant, then you can pretty much guarantee that
Authentication-Results: will appear immediately above (or perhaps
immediately below) a matching Received: header, and thus you could decide
to trust only those which (a) have such an adjacency, and (b) are from a
host you trust.
And yes, I like that, though it is perhaps less likely to be implemented
by MUAs. Presumably the hope is that future MTA will, when they spot a
believable Authenticated header, display a Large Green Tick beside the
message, so that the naive user will be suitably reassured
The Large Green Tick only gets put there if you've suitably
authenticated the message *AND* you have a positive reputation
associated with that domain and/or user.
Remember, joe.spammer.com can use DKIM also. I would want
joe.spammer.com to get a Large Red Stop Sign instead.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html