On Wed, 08 Oct 2008 17:52:51 +0100, Murray S. Kucherawy
<msk(_at_)sendmail(_dot_)com>
wrote:
The proposals the current draft suggests, which are listed briefly in
Security Considerations, include:
a) interrogating the previous MTA to determine if it's participating in
this specification such that dangerous Authentication-Results: headers
are
being removed; and
That looks like an SMTP extension, which is a huge big can of worms.
But surely, as others have pointed out, if you (as a mere user) have
chosen to subscribe to the services offered by MTA-X, then presumably you
know what they do, and also presumably you trust them.
The scam we are trying to avoid is where the phisher has signed his
message with a plausbible-looking but invalid signature, and backed it up
with a bogus Authenticated header apparently placed there by what he
"presumes" to be the correct identity of your delivery MTA (culled from
your MX record), in the hope that your delivery MTA does not implement
DKIM checks. That would work sometimes (often enough to be useful,
perhaps), but can break down for any number of reasons (e.g. his
"presumnption" was wrong, your delivery MTA may spot it, you are
suspicious because you know that your local MTA does not do DKIM).
b) digital signing of the Authentication-Results: header, e.g. with DKIM
If your MUA is capable of verifying such a signature by MTA-X, then it is
presumably equally capable of verifying the original DKIM signature which
the Authenticated header is attesting to.
Nevertheless, for the paranoid user, adding such a signature should be
regarded as good standard practice, so I would not object to saying that
MTA-X SHOULD do it.
The spec doesn't actually mandate either of these. It sounds like the
IESG would likely want one or the other.
I would say the IESG are over-reacting a bit.
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 :-( .
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
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html