Matt, Do you have an updated version of your tests.
Thanks. Fred ----- Original Message ----- From: "Matthew Bramble" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 9:27 AM Subject: Re: [Declude.JunkMail] Bad header question > Thanks a bunch for the clarification. It's just unfortunate that > programs that make the mistake of using an IP as a hostname and not > including a message ID end up failing so many important tests. I > recently been seeing about 2 different senders each week that will FP > for this reason (but no longer fail), unfortunately one of them is > always Volkswagen who uses a free version of an ActiveX control to mass > mail their dealer principles. That SPAMHEADERS tweak helps these > messages pass my config, and I haven't noticed any bad effects. Just to > be totally fair, the vast majority of messages that fail with this error > are spam. Now that I've grown an appreciation for filtering, I'm > perfectly content with adding a couple of lines to a text file instead > of thinking you might need to change BADHEADERS...it's just a shame to > see that test FP on anything. > > One of my problems is that I have too many clients receiving > communications from some of the biggest hack-job servers around (the > automakers often do this). Then GM's customer response system for > Internet inquiries will turn around and block your message because a > broken reverse DNS delegation caused your lookup to fail. I actually > talked some sense into those people I think, but tracking down the > person in charge of the Central Northeast sub-department of Keychains > and Tie-tacks that uses non-compliant software for sending mail blasts > out is hardly even worth the trouble. The good thing is that the > dealers receive so much of this crap from them on a daily basis that > they never even bother to read it. > > Matt > > > R. Scott Perry wrote: > > > > >> Josh is right. Declude doesn't like seeing IP addresses in Message > >> ID headers. > > > > > > Just to clarify, there were two problems with this E-mail: > > > > [1] The Message-ID: header wasn't present when the E-mail was sent (it > > was added by IMail after the E-mail was received). This caused the > > E-mail to fail the SPAMHEADERS test. > > [2] The Message-ID: header that IMail added was bogus, because it > > generates the Message-ID: header based on the HELO/EHLO data, which in > > this case was bogus. Since the Message-ID: header is bogus, the > > E-mail failed the BADHEADERS test. > > > > The beauty of IPs in Message-ID: headers is that they *are* allowed -- > > but only if they are formatted correctly. In the class "RFC821 101" > > (one that is required by everyone that programs mail clients or > > servers), you learn that IPs in E-mail headers always appear in > > [brackets]. So "Message-Id: > > <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED] 182.0.220]>" > > is perfectly valid, but "Message-Id: > > <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED] 82.0.220>" > > is not. > > > >> I see FP's from BADHEADERS for the same. > > > > > > FYI, E-mail will only fail the BADHEADERS test when something is > > broken (not RFC-compliant). Either the mail client, or something > > along the way (HELO/EHLO in this case). > > > >> SPAMHEADERS get's triggered for exactly the same reason. > > > > > > For a similar reason. There is no one fault that will cause an E-mail > > to fail *both* the SPAMHEADERS and BADHEADERS test. If there is > > something that will fail one of the tests, it will fail the > > SPAMHEADERS test if it is legal, or the BADHEADERS test if it is not > > legal. > > > > In this case, it failed the SPAMHEADERS test for the missing > > Message-ID: header when the E-mail was sent, and then the BADHEADERS > > test for the bogus Message-ID: header that was added. Had the sender > > sent the mail properly, the HELO/EHLO would have been legal, and the > > Message-ID: header that IMail added would have been legal. In this > > case, only the SPAMHEADERS test would get triggered. > > > > -Scott > > > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. > --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
