Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: base64
From: Christian Vogel <chris () obelix hedonism cx>
Date: Thu, 25 Sep 2003 09:10:04 +0200

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]