Well, actually I collected some of this data as well. But without
corresponding data on non-spam, it's not very useful. Certainly each
of the steps you outline includes an increased number of false
positives.
There were 7376 unique senders.
4298 had some "problem" with the HELO or DNS information.
10 No A record for the HELO domain
Is <domain> equivalent to <host> or was there a reason for that particular
change between RFC788 and RFC821? For example did RFC822 legitimize HELO
EXAMPLE.COM from the host MAILSENDER42.EXAMPLE.COM? If the change was
meaningful, you should not expect thee to be an A record.
702 The hostname for the HELO doesn't resolve
There isn't a hostname to resolve, is there? So why should this imaginary
thing resolve?
1330 Unqualified domain in the HELO
2030 Sender domain does not match the HELO
What does "match" mean? Does A.B.COM match B.COM? Does B.COM match
A.B.COM? (Is "match" symmetric?). If these don't match, expect false
positives from people whose mailservers use a host (rfc788) in helo, as the
transmitting MUA may not run on that machine.
<snip>
Obviously those all overlapped a good deal. Your immediate reaction
might be to make sure that the sender domain matches the HELO. After
all, it would nail half the spam right there. But then again, it
would also block most of the mail coming from my domain and many
others. My mail server always uses the primary domain name in the
HELO, no matter which domain it sends for. That's probably true of
most servers.
Quite so. That's why RMX records or some other scheme to achieve the same
effect may be useful.
Tom
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg