Re: [exim] NUL characters are not allowed

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Exim User's Mailing List
Date:  
À: Jack Ziegler
CC: Exim User's Mailing List
Sujet: Re: [exim] NUL characters are not allowed
[ On Wednesday, October 13, 2004 at 08:20:44 (-0700), Jack Ziegler wrote: ]
> Subject: [exim] NUL characters are not allowed
>
> We're having problems with a handful of sites that reject messages with
> a 550 error, and the explanation "NUL characters are not allowed". I
> know that RFC 2822 specifies that a conformant receiver must accept
> messages with NUL, even though NUL is no longer allowed.


Yeah, well, RFCs are not policy statements for any given site, and
they're most especially not security requirements for any given site.

NUL characters are not, and never have been, allowed in IMAP messages
and if the receiving site wants to safely use IMAP then they must not
allow NUL characters in their incoming SMTP either.

Besides, you have no excuse for even trying to send a message with a NUL
in it in the first place -- you're not allowed to according to the RFC. :-)

(depending on what conformance level you claim for your mailer of course :-)


> What's most
> irritating is that the problem tends to happen on replies to messages
> that actually originated on another machine at the site that's
> rejecting the message. The offending NUL appears in quoted text from
> the original message.


That is interesting -- though I wouldn't consider it "irritating" in any
way. How do you know the original message was transmitted through the
same machine(s) or even machine(s) with the same policy?

It does _seem_ to violate the academic "be liberal in what you accept
and be strict about what you send", but this issue is so closely tied to
security that the robustness principle really cannot apply. (protocol
robustness is, and MUST BE, wholely separate from the data content
carried by the protocol!)


> Unfortunately, one of the people affected is the campus CIO, so I'm
> making an effort to find a local workaround.


Well, you might try configuring your CIO's mail reader properly so that
it MIME-encodes the offending message. :-)

-- 
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>