Hi David, > 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 messages. > "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 > present." 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. Chris -- 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
