[Greylist-users] HELO

[Eric S]

On Mon, 21 Jul 2003, Brian Grossman wrote:

> > nor a single part that matches the leftmost part of the rDNS.
>
> Be careful with that one.  It's fairly common for hosters to consolidate
> outgoing mail.  When I tried it several years ago for example, I stopped
> receiving email from compaq (RIP).

Could you explain that in a little more detail, not sure I follow what
you're saying.

My HELO rules are as follows (first match applies).

1) If the ip address the connection is coming from is whitelisted, pass
it.

2) If the HELO is one of the domains that this server is responsible for,
fail it.

3) If the HELO is an unbracketed IP address, or my IP address even if
bracketed, fail it.

4) If the HELO doesn't contain a period *AND* it doesn't match the
leftmost part of the rDNS, fail it.  So, a HELO of foo.bar would pass the
first condition, and a HELO of mail coming from an IP address with
mail.example.com as its rDNS would pass the second condition.

This much is implemented.  On the machine I admin for work, we aren't
doing greylisting yet (I want to bring the OS up to date before I install
a threaded perl) we also have these rules:

5) If the HELO is a FQDN, check to see if it resolves.  If so, pass it.

6) Drop the leftmost portion of the HELO, and if that resolves, pass it.
This way, if someone helo's with outmx.example.com, outmx.example.com
doesn't have to resolve if example.com does.  This is an important step,
because many sites have a machine HELOing with a name that is only
visible internally.

At no point am I checking to make sure that the HELO has any bearing on
the env-from, nor am I checking to make sure that what it resolves as
has any bearing on the ip address that the connection is coming from, so
consolidating has no effect on this, if I understand you correctly.  In
fact, this is trivially spoofable, because any HELO that resolves works,
even if it has no relationship to the rDNS.

Now, DHVP (there was a flurry of talk on the design of DHVP last week
on spam-tools, it's a method of verifying that a machine is allowed to
send email out according to the domain it HELOs with) would be a different
story, but since I'm not implementing that, then I can get away with what
I'm doing with practically no false positives.  The only false positive
I've had so far was because my filter isn't taking temp DNS failures into
account, which is something I'd like to change.

If I'm missing something, I'd really like to know.  I'm still fiddling
with my greylist implementation, so I don't know how that's going to
affect the attributes of the spam that makes it to my filters.  I suspect
that greylisting will significantly reduce the effectiveness of HELO
testing, since the bad HELOs are mostly coming from proxies that aren't
going to retry anyway.