On Mon, Feb 06, 2012 at 04:04:53PM -0800, Don Armstrong wrote: > On Mon, 06 Feb 2012, brian m. carlson wrote: > > I'm asking you to please fix your mail server so that it doesn't > > send or relay invalid data. exim tends to be broken WRT 8BITMIME, > > which is exactly why I don't use it. > > There are a few reasonable alternatives: > > 1) We fix the mail to be proper 8 bit mime
I don't know how you can do this. The major case that I see is an email containing 8bit data but that is not MIME. Since the message is not MIME, it does not contain a Content-Type header. The default content type is therefore "text/plain; charset=us-ascii". However, since the message contains 8bit data, it is obviously not ASCII. How is the mail server to determine the proper character set?[0] If a character set is not provided, the data are useless since they cannot be displayed reliably. Guessing character sets has proven to be a bad idea in general. Omitting the charset parameter in a synthesized Content-Type: text/plain header would result in it being valid MIME, but since the default charset is us-ascii, the data would still be useless. > 2) We follow Postel's law and resend the message since it can actually > be understood, possibly adding to the spam score if the message > appears to be 8bitmime but isn't actually a valid mime message. I just want to point out that even debian-security-announce sometimes has 8bit non-MIME messages, so you might want to take announce lists into account when scoring. Many of the invalid messages appear to be legitimate email for the lists. Some are clearly spam. The issue is using the protocol correctly, not stopping spam (although that is a pleasant side effect). Of course, this alternative still sends invalid data, so you'll continue to get SMTP rejects. This also would not fix this bug. There are also a few other alternatives: 3) Do not accept 8bit messages that are not MIME. This will catch a decent amount of spam, IME. It also forces the sender to fix his/her mail setup. This makes generating Content-Type headers (and charset parameters) the job of the sending MUA, which is the only place which can possibly know the charset for certain. 4) Accept and silently discard 8bit messages that are not MIME. This is probably not an acceptable alternative, but I proposed it for completeness. [0] Distinguishing between the ISO-8859 variants requires language analysis of the text in order to get a reasonable guess and even then distinguishing ISO-8859-1 and ISO-8859-15 may just not be possible for a non-human. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
