Why do we care? If Y is reputable, and it says X is OK, we have
what we need. If Z is forged, we tell Y, and they fire X.
It'd be a simple matter of granularity. In your example you can
either trust relay X completely, or not at all. A bit crude,
don't ya think?
The granularity of the HELO name is controlled by the sender, as it
I'm talking about the 'receiver' granularity of making a determination
based on HELO. And since the same relay will almost always use the same
HELO,'receiver' granularity is close to zilch in that scenario.
If X can't get control of spammer accounts on its webmail servers, or
whatever, it would be very easy for them to use a different HELO name
for those servers.
In other words: let the legit relay determine what is spam, and let him
set a HELO accordingly? I'm afraid that doesn't make much sense. Other
than that you make spam-fighting an almost entirely passive operation that
way, having to rely on the goodwill and HELO of a legit relay who
allegedly already set a spam-HELO to indicate that the message to follow
will likely be spam, such a relay would be guilty of willingly sending out
spam in the first place. If you find a spammer on your server(s), you yank
his account, clear and simple; you don't let him send under a different
HELO. And if you're not the admin with sufficient privileges to remove his
account, then you notify someone who is. And if you ARE that admin, but
don't know how to remove the offending account anyway, then you notify
someone to remove you. :)
My ISP's servers (not my own) use a different strategy: they incorporate
the user account name in the HELO. Not even all that bad an idea, in terms
of helping receivers determine accountability. But it's a very rare thing;
and, for sendmail at least, I know it would require a customization of the
C source to get it to do that. So, I don't think we can really count on
such behaviors. The safest bet, way I see it, is to bank on the fact that
the HELO of the connecting client will not actively help you to make the
distinction between spammer and non-spammer (in terms of who uses his
relay), except in determining the overall status of whether said relay
itself is trustworthy or not. Hence, the lack of receiver granularity.
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com