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]>" is perfectly valid, but "Message-Id: <mailto:[EMAIL PROTECTED]><[EMAIL PROTECTED]>" 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.
