>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".
>I'm sure they are not the only person using Act.
No, there are others.
>Has anyone seen a way around this? I don't want to raise our threshold to
>something like "18", as that will let in a flood of SPAM that is currently
>being blocked.
>However, ACT (and Maximizer, another CRM system) are widely used and need
>to work properly.
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.
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.
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.
FYI, IMail does add a Message-ID: header if there isn't one already (since
IMail knows the importance of the header). So, even though you see one, it
was added by IMail.
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).
-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". You can E-mail
[EMAIL PROTECTED] for assistance. You can visit our web
site at http://www.declude.com .
