On Sun, 15 Aug 2010 04:50:13 +0100, Daniel Black
<daniel(_dot_)subs(_at_)internode(_dot_)on(_dot_)net> wrote:
If users are to place value in From headers as MUAs display and ADSP
tries to
enforce then manguling From headers is adds complexity to the
interpretion of
the header field by to the end user.
If the original was
From: Joe Doe <joe(_at_)discardable(_dot_)example>
and a recipient sees it as
From: Joe Doe <joe%discardable(_dot_)example(_at_)mlm(_dot_)example>
then he will still have a pretty clear idea that it originated from Joe
Doe, and may even be able to correctly guess Joe's original email address
even if he is unfamiliar with the percent-hack.
ANNEX A - MUA Considerations
A MUA could implement the following features to reduce the need for
signature
modifications:
* Display of the List-ID header field is used to be displayed beside
where a
subject header field is displayed.
* functionality to create a filter based on based on the List-ID header
field.
I agree it would be a Good Thing if MUAs routinely displayed some of the
List-* headers as a default feature.
But you seem to be suggesting that an MUA should be setup to accept
mesages with a List-Id plus a valid signature from the MLM, even from a
discardable origin.
Ignoring the fact that such emails may be already discarded by some
boundary agent, that is still an open invitation to every Phisher to add a
List-ID from some bogus list to every message he sends, and to add a valid
signature from that bogus list (and perhaps even a deliberately invalid
signature from the phished domain).
Somehow, MUAs need to be aware of which lists the user is subscribed to if
they are going to do that sort of thing.
--
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