headers
Murray S. Kucherawy | 8 Nov 2010 06:28

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

Some time ago I started looking into what the consensus is for various MTAs' handling of common
malformations of email messages and MIME structures.  The collected wisdom thus obtained so far appears
in the draft I've introduced, which is only meant as a starting point for such a collection of other cases.

There was some consensus that this would be a useful effort to start, so here I am starting it.  :-)

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.

-MSK
Picon Favicon
From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
Subject: New Version Notification for draft-kucherawy-mta-malformed-00
Date: 2010-11-08 05:20:24 GMT

A new version of I-D, draft-kucherawy-mta-malformed-00.txt has been successfully submitted by Murray
Kucherawy and posted to the IETF repository.

Filename:	 draft-kucherawy-mta-malformed
Revision:	 00
Title:		 Best Current Practices for Handling Malformed Messages
Creation_date:	 2010-11-07
(Continue reading)

Permalink | Reply |
headers
Martijn Grooten | 30 Nov 2010 18:26
Favicon

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


(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.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.
(Continue reading)

Permalink | Reply |
headers
Douglas Otis | 30 Nov 2010 20:10

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
(Continue reading)

Permalink | Reply |
headers
Murray S. Kucherawy | 30 Nov 2010 20:55

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


> -----Original Message-----
> From: owner-ietf-822 <at> mail.imc.org [mailto:owner-ietf-822 <at> mail.imc.org] On Behalf Of Douglas Otis
> Sent: Tuesday, November 30, 2010 11:11 AM
> To: Martijn Grooten
> Cc: ietf-822 <at> imc.org
> Subject: Re: New Version Notification for draft-kucherawy-mta-malformed-00
> 
> 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.
> [...]

I think this is completely off-topic for the work being discussed here, Doug.  The discussion has to do with
what MTAs, and perhaps MUAs if that's appropriate, should do with common malformations independent of
things like DKIM.
Permalink | Reply |
headers
Douglas Otis | 1 Dec 2010 00:06

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


On 11/30/10 11:55 AM, Murray S. Kucherawy wrote:
>> On Tuesday, November 30, 2010 11:11 AM, Douglas Otis wrote:
>>
>> 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.
>> [...]
> I think this is completely off-topic for the work being discussed here, Doug.  The discussion has to do with
what MTAs, and perhaps MUAs if that's appropriate, should do with common malformations independent of
things like DKIM.
Murray,

Any deviations from standards normally used by malefactors to deceive 
recipients should be rejected!  Unfortunately this draft suggests:

1) Ignore
2) Repair
3) Reject

Ignoring and repairing remains problematic.  IMHO, repair will never be 
required for SMTP or MUA level compliance.  Without format compliance 
being part of trust related verifications, systems claiming enhanced 
levels of trust will not be trustworthy.  Since SMTP does not mandate 
non-compliance be rejected, the only reasonable strategy is to ensure 
mechanisms such as DKIM makes no exploitable assertions when confronting
(Continue reading)

Permalink | Reply |
headers
Hector Santos | 1 Dec 2010 17:01

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


+1

Once it becomes a subjective design with indeterminate states, the 
game is over. But then again, that is probably what this draft is 
looking for - narrowing down some of the subjective designs because 
maybe they are not subjective and can fall under a non-compliancy status.

IMV, not much will be done (expend resources, time and money to change 
software) unless there are security related issues.  The multi-from 
issue and how it related to DKIM is one of them.  This particular 
discovery should be shared for the rest of the non-dkim world to mitigate.

--

-- 
Sincerely

Hector Santos
http://www.santronics.com

Douglas Otis wrote:
> 
> On 11/30/10 11:55 AM, Murray S. Kucherawy wrote:
>>> On Tuesday, November 30, 2010 11:11 AM, Douglas Otis wrote:
>>>
>>> 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
(Continue reading)

Permalink | Reply |

Gmane