mailing list archives
From: Christian Vogel <chris () obelix hedonism cx>
Date: Thu, 25 Sep 2003 09:10:04 +0200
RFC 2045 states (section 6.8):
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances."
A user-agent has to assume that it's message might be dropped if it
creates base64 with junk in it. So it should not create these things
and it's perfectly resaonable for a MTA/virus-scanner to drop those
"Because it is used only for padding at the end of the data, the
occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are
Again, as the mail-client does not have a way to know how the generated
data is interpreted in those ambigous cases its reasonable to just
drop those messages.
But there are too many common email user
agents which generate non-conforming messages.
Is there already a list of broken MUAs? Do the vendors even know
(yes, they should have cought that during testing... ;-) )
Or should we reject all these broken messages? ;-)
Either reject them or convert them to a canonical form. But that will
generate further problems, e.g. if you modify signed payload that way.
Message passing as the fundamental operation of the OS is just an
excercise in computer science masturbation. It may feel good, but you
don't actually get anything DONE. -- Linus Torvalds