Hi Scott..... At 02:15 PM 2/25/2002, you wrote:
>>I have a customer who has not been able to send email through our system. He >>was scoring a "17" on the spam scale. Here's the relevant detail from >>the log: >> >>02/25/2002 13:23:37 Q811f28a BADHEADERS:8 REVDNS:4 SPAMHEADERS:5 . Total >>weight = 17 >> >>Well, we determined that the person sending messages was using >>Symantec's ACT program's internal email client, and that it does not meet >>the criteria set out by Declude. > >Or, "the criteria set out by the RFCs that ACT is expected to follow". Of course.... >Well, the best way to handle this is for the admin at the remote mail >server to add a reverse DNS entry (which the RFCs do require, even though >many mail servers do not have a reverse DNS entry), and to get ACT to get >their act together and follow the RFCs. They are sending through our mail server, and we do have reverse DNS configured for the domain of the mail server. For the others - which are "virtuals" under IMAIL - what reverse DNS do we need - for their website? They don't have a direct IP to a mail server - they just have an MX record pointing to our main mail server (mail.cydian.com) >Without seeing the headers of the E-mail in question, I can't say exactly >what is wrong, but the codes that Declude uses give a clue as to the >problem. It looks like the programmers of ACT made up their own time >zones to use in the headers. Note that not only might this cause the >E-mail to be treated as spam, but lots of mail clients will "lose" the >E-mail to the top of the inbox (because they have no idea when it was >sent, and will have to guess). That's a serious issue -- the version of >ACT they are using is broken. They should upgrade to the latest version, >which should certainly fix this problem. They are running the latest version. Apparently, Symantec sold Act to another group that has not updated it in about a year. Yes, they SHOULD fix this, but in the mean time, for our customers, we need to handle the situation as it is, not as it should be. >The other issue (the one that causes it to fail the SPAMHEADERS test) is >that the programmers of ACT were lazy and decided not to add a Message-ID: >header. The Message-ID: is not required in order for an E-mail to be >valid, but the RFCs say that it "SHOULD" be there. "SHOULD" in RFC >terminology means that the header must be there *unless* there is a good >reason for it not to be there, and the consequences of it not being there >are known. I can't think of a good reason for the Message-ID: header not >to be present (except that it saves programming time). The consequences >of not having a Message-ID: header is that the mail may or may not be >delivered if it is missing. Is there a way to eliminate this single test? It is causing false positives, both with this & Cold Fusion customers (CFMAIL also leaves out the Message-ID) >But, if you can't get the senders of the E-mail to fix the problem, you >can whitelist them (for example, by adding "WHITELIST FROM @example.com" >in the global.cfg file). Already did.... Thanks Chris --- [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". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com .
