I had the same problem when using symantec av smtp gateway and some = clients too with some avs ...
First, note that a pure mta have nothing to do with the message itself (expect to add its own Received from, etc, in the header part) and have = not to control it. The pure mta actes on tcp/ip smtp session data only (and = have to control it with rfc rules). AV gateways are like xmail + filters, a mta and content filters. So now, at filter stage : The headers part of the message can't contain a null, as any line in = the headers part have very strict writing rules in the rfc's : only subset = of printable chars from 32-127 and cr/lf. Then after the empty line, begins the message body. The problem is how filters programmers read the rfc and how they class = a null char : "The mail data may contain any of the 128 ASCII characters. All = characters are to be delivered to the recipient's mailbox including format = effectors and other control characters." "128 ASCII characters" : strictly reading is it 'From 0 to 127', so a = null byte in the mail is ok. Some don't classify the 'null byte' in the 'characters class' nor the 'control characters class' : then null byte is not ok. And another point to verify in rfcs, assuming 'a null byte' is a ASCII = char (yes it is ...): Don't know exactly if MIME RFC's says anything about null and others = control caracters, but 'in mind' in a MIME formatted message, any 'special' character (not in range 32-126) need to be encoded, so a null byte have = to be encoded, then finaly a MIME formatted message can't contain a 'pure' = null byte in the data ... If you don't create a MIME message (only plain text from 0-127 char = set, no mime headers, no possibility for attachements and multiple formats in = same mail, ...), you can have 'pure' null bytes in the data,=20 but if creating a MIME message you can't. The AV problem can then simply be a bug if the mail in not a mime = message .... but the filter don't check and allways assume a Mime message. Francis > -----Message d'origine----- > De : John Kielkopf [mailto:[EMAIL PROTECTED] > Envoy=E9 : vendredi 27 mai 2005 14:56 > =C0 : [email protected] > Objet : [xmail] Re: Stange mail "clogging" up POP. >=20 >=20 > John Kielkopf wrote: >=20 > >S=F6nke Ruempler wrote: > > > > =20 > > > >>[EMAIL PROTECTED] <> wrote on Friday, May 27,=20 > 2005 2:58 AM: > >> > >>=20 > >> > >> =20 > >> > >>>On Thu, 26 May 2005, John Kielkopf wrote: > >>>=3D20 > >>> =20 > >>> > >>> =20 > >>> > >>>>Have a strange problem here. > >>>>=3D20 > >>>>Users that have Norton Internet Security or Mcafee "Spam Killer" > >>>>active have trouble with mail clogging up their systems=20 > from time to > >>>>time. Disabling the products lets them receive the mail. > >>>>=3D20 > >>>>Although these users complain that they never had these=20 > problems with > >>>>any other mail server, this doesn't seem to be an Xmail server > >>>>problem. However, I'm wondering if any of you have come up with a > >>>>good solution, other than telling the users to disable these > >>>>products, of filtering mail that's causing these problems, and/or > >>>>what exactly it is about these messages that creates this = problem. > >>>>=3D20 > >>>>Here is an example of one of the messages, pulled=20 > directly from the > >>>>mailbox and zipped: http://207.67.28.206/bademail.zip > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>=3D20 > >>>It's a badly formatted MIME message (there's a '\0' towards > >>>the end of the > >>>message). Probably this confuses the heck out of the two junk > >>>software you mentioned. > >>>=3D20 > >>>/me hides from MFE revenge > >>> =20 > >>> > >>> =20 > >>> > >>Yes, Norton AntiSpam (Symantec crap ;) ) has this null-byte=20 > problem but > >>they don't seem to care about it. Maybe other MTAs do=20 > filter nullbytes? > >> > >>=20 > >> > >> =20 > >> > >However, from RFC 821: > > > > "The mail data may contain any of the 128 ASCII=20 > characters. All > > characters are to be delivered to the recipient's mailbox > > including format effectors and other control characters." > > > >To me, this sounds like a null byte would fall in the "any=20 > of the 128=20 > >ASCII characters" range. > > > >That said, I've sent sample messages and a description of=20 > the trouble to=20 > >Symantec and Mcafee long ago, and apparently there's still=20 > no fix -- so=20 > >I guess I'll need to come up with some sort of workaround. =20 > Does anyone=20 > >see any problems with filtering it? > > > > > > =20 > > >=20 > Just a quick follow-up: >=20 > It appears some major ISPs are checking for null bytes. See this=20 > response from a comcast server: >=20 > SMTP module(domain comcast.net) reports: > message text rejected by gateway-r.comcast.net: > 556 null byte in data >=20 >=20 >=20 > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] >=20 - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
