From: <[EMAIL PROTECTED]>
On 12/7/05, Kai Schaetzl <[EMAIL PROTECTED]> wrote:
Not an incorrect format, but probably a format that SA mismatches, yes.
Looking at the rules (which look rather complex, so I may misinterpet it)
it seems it matches on the "dsl" part and on the IP address of the header
line instead of the HELO string. What's that MTA? Exim, Qmail?
The MTA is sendmail, but actually the Received: header is added by
Mail Avenger (an SMTP server that runs the mail through spamassassin
before passing it to sendmail).
The Received header is patterned on Received headers added by some
version of sendmail. Of course, since sendmail sets the format based
on sendmail.cf, there have probably been many different formats, but
it probably means this problem could affect other people.
If SpamAssassin has some particular prefered format for Received
headers, I'd certainly consider changing the format for the next
release of Mail Avenger. But if this is something that SpamAssassin
could fix, that would be good, too.
<< David, as Kai has tried to point out a couple times now, their
reverse DNS record is not EVER going to get past dialup list detection.
Let's play a little. We have this information:
Received: from adsl-71-133-227-154.dsl.pltn13.pacbell.net
(71.133.227.154) (HELO genstor.com)
It claims to be genstor.com. If I look up their MX record I get the
address of their name server: ns4.genstor.com. If I look that up I get
71.133.227.154. So far "sort of" so good. Now if I perform the reverse
lookup I get something WILDLY different that includes "dsl" in it
twice. This is a very typical reverse dns lookup on a dynamicly assigned
address. There is NOTHING going to get that address through the spam
assassin tests. (If it did I'd recreate the tests and install them here.)
If PacBell.net cannot see to setting up a PROPER rDNS record for the
company they're basically sunk even though they are (apparently) not on
any formal DUL lists.
The problem is NOT the format. It is the basic data content that is hosed.
{^_^}
