On Thu, 09 Oct 2008 21:08:42 +0100, Murray S. Kucherawy
<msk(_at_)sendmail(_dot_)com>
wrote:
Proposed diffs from the -16 draft, based on this discussion so far, are
attached.
+ An MUA or filter that accesses a mailbox whose mail is handled by a
+ non-conformant MTA, and understands Authentication-Results header
+ fields, could potentially make false conclusions based on forged
+ header fields. A malicious user or agent could forge a header field
+ using the destination MX for a receiving domain as the authserv-id
+ token in the value of the header field, and with the rest of the
+ value claim that the message was properly authenticated. The non-
+ conformant MTA would fail to strip the forged header field, and the
+ MUA could inappropriately trust it.
Which suggests a much simpler answer to the whole problem. The authserv-id
is chosen by the MTA. So you simply state that the authserv-id MUST NOT be
the domain name of the MTA as obtainable from the (any) MX record, or be
easily derivable from it. That is not to say it may not contain that
domain name, but it must also include some other "magic word" which could
not be guessed by the Bad Guys, but which could be hidden in the
documentation provided by that HTA to its end users.
Bear in mind that phishers are in the business or emailing their scams by
the million, addressed to random recipients culled from a variety of
sources, thus making it totally unprofitable to do the necessary research
to discover the "magic word" for other than a small proportion of them.
--
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