Re: New Version Notification for draft-kucherawy-mta-malformed-00

On 11/30/10 9:26 AM, Martijn Grooten wrote:
> (Reposted to the list as per Murray's suggestion.)
>> Please do feel free to review what's there and comment, and also submit
>> suggestions for other cases that might be of interest to record for
>> future implementers.
> A couple of things:
>
> - an example of non-valid header I have seen "in the wild" (in legitimate email) is a non-encoded non-ASCII header (something Russian, I believe). I'm not quite sure how this can be abused though, but it's probably worth mentioning. I know at least one spam filter that does (or did; I think they changed it) block such messages outright as non-valid email.
>
> - it's not mentioned in the document, but in the related discussion on the DKIM-list, "actions" to be taken by MUAs were implicitly or explicitly mentioned. I just wanted to say I don't think a MUA _should_ do anything but, perhaps, render a message in a specific way. Many people have filters built in their MUAs, but many others haven't.
>
> - it would be great if the document could somehow say it is okay for a filter to discard/deny/drop certain kinds of messages. (Multiple From-headers, for example.) I know many spam filters don't dare to do this, as there is always the risk of false positives and the need to be liberal. A document like this could give them some kind of official 'permission' to block these messages which would, hopefully, encourage both legitimate senders and spammers to not send them.
Disagree.

DKIM should be repaired to ensure deceptive malformed header fields do 
not verify as having valid DKIM signatures to prevent the exploits, such 
as having multiple singleton header fields invalidate signatures.  DKIM 
should have included checks necessary to disqualify messages likely 
crafted by malefactors.  These checks may need to grow over time.  The 
impact of adding checks to DKIM's verification process will not justify 
new mandates for making message repairs or rejections by SMTP or MUAs.

DKIM uniquely attempts to leverage use of header fields, unlike S/MIME 
or PGP.  As such, ensuring against deceptive malformed header fields 
from receiving DKIM validation is reasonable.  This is the value 
proposition of DKIM after all.  Expecting rejection or repair of such 
header fields is likely to prove counter productive at providing 
compatible DKIM validations.

-Doug