Eli Sand wrote:
>> Consider this. Suppose a host send email and their helo matches the
>> host
>> RDNS, and I store that. Then later a different host uses the same helo,
>> but they have no RDNS or that are on a dynamic IP. Wouldn't that be a
>> strong indicator of spam?
To Marc:
Dunno if it is Alzheimer's at a young age, or just a compulsion to keep
re-inventing the wheel until it reaches an incrementally higher level of
perfection - or at least is a different-looking wheel..
;-)
But let's see:
>
> Consider a mail host provider that provides email to many different
> hosts/clients, which is set to HELO with the hostname of the client it's
> sending email out as (sure, you may argue it's not proper, but people may do
> it). You would end up thinking this server (or cluster of servers) is
> sending spam.
Perhaps.
Standards DO permit pointing more than one PTR RR to a given IP. Some
do it with long lists - we've done it once, with three, but won't do it
again.
Aside from lookign suspicious in its own right, it brings its own lookup
issues, primarily because one has no control over *which* of the several
<domain>.<tld> are returned to a caller, or whether the entity making
the query seeks to retrive the full list and parse it for whichever HELO
was used.
IOW - 'unpredictable'
A better solution, IMNSHO, is to utilize one 'mothership' domain.tld
and set of records and keep them consistent regardless of which client
MAIL FROM.
Not surprisingly, this is what most hosting providers do.
>
> Consider a cluster of mail servers behind a load balancer that balances
> outbound as well as inbound on one IP. Technically each server should HELO
> under their actual names (could be local - I don't believe RFCs state it
> must be a valid public hostname),
'FQDN' 'strongly implies' that it be found with a common DNS query
;-)
> but they would send email out under one
> common IP. You'd block this as well.
>
ACK. But you *could* assign a few not-fatal-on-their own 'demerits',
then sum these with demerit points from other not-quite-right
characteristics, and use the cumulative score to *at least* warn in the
subject line, add a header (who even *sees* those?) or outright divert
to a quarantine folder.
Or even - perish the thought - deny/drop/defer quite early in the
connection.
We do all of the above, plus a few short, but strategically placed delays.
Essentially a 'quality' rating of the level of RFC and BCP compliance of
the sending host. Needless to say, zombots fail on nearly all counts.
The a concept was expounded here by others long before we arrived.
- every part of it has been learned right here on the Exim list.
- essentially ALL of it relies on what was available in 'year one'
.... of the *original* smtp RFC.
'if it ain't broke....'
... just be a bit less 'generous in what you accept..'
> I've recently started using a new domain name for email and I have not
> changed my Exim config in about a year dealing with spam filtering. I
> hardly receive any (actually, I can't really remember the last time I had
> spam in my inbox come to think of it) spam these days. I used to receive
> tons of spam on my old domain name, and no filtering techniques changed
> since then, so the amount of spam I get must be due to something with the
> domain name... Perhaps you should tell your clients to a) stop using their
> email address everywhere that has a "enter your email address!" (or use
> temporary accounts for those reasons), b) if the registrar supports it, hide
> registrar info and kill the contact address. I give you this tiny story
> because I'm surprised that you, still, have to try and think up new ways to
> block potential spam. I'm certain you've thought of everything and are
> probably grabbing air in hopes to come up with something new. Perhaps it's
> just up to your clients now to utilize their email with caution instead of
> assuming your servers will shield them from the ugly side of the Internet.
>
> Eli.
>
>
Many less common <tld> are near-as-dammit ignored by zombots.
For a while.
But your address is dead certain to eventually get into circulation, if
only because some of your correspondents WILL still be running Windows...
;-)
Bill Hacker
