[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Networking -- use of two Internet connections for one server with round robin DNS -- web okay, but should I do mail this way too?



On Sun, 10 Jul 2011 01:47:19 +0200
lee <lee@yun.yagibdah.de> wrote:


> So there isn't any check on what's given in the [E]HELO statement with
> this.  Now I've spent about tow hours trying to figure out how to
> check if the $sender_helo_name is resolveable and didn't get anywhere
> other than finding out that it could be done easily with something
> like ${lookup dnsdb{a=${sender_helo_name}}{$value}fail}.  The exim
> syntax is horrible with things like that :(  I need to look into that
> some more ...

> 
> > There's no need for the HELO to match the PTR,
> 
> Thank you for the clarification; I was obviously wrong.
> 
> 
Yes and no, see later. I've run with unmatched HELO and PTR for at least
seven years, and never had a rejection on that basis. I don't send to a
huge range of ISPs, but it does include AOL, which is notoriously picky.
What I do have is the HELO resolving to my IP address, even though the
PTR is something else.

From the exim4 specification:

"The RFCs specifically state that mail should not be refused on the
basis of the content of the HELO or EHLO commands. However, there are
installations that do want to be strict in this area, and to support
them, Exim has the helo_verify option.

"When helo_verify is set, a HELO or EHLO command must precede any MAIL
commands in an incoming SMTP connection. If there wasn't one, all MAIL
commands are rejected with a permanent error code. In addition, the
argument supplied by HELO or EHLO is verified. If it is in the form of
a literal IP address in square brackets, it must match the actual IP
address of the sending host. If it is a domain name, the sending host's
name is looked up from its IP address (whether or not it matches
host_lookup) and compared against it. If the comparison fails, the IP
addresses associated with the HELO or EHLO name are looked up using
gethostbyname() and compared against the sending host's IP address. If
none of them match, the HELO or EHLO command is rejected with a
permanent error code, and an entry is written in the main and reject
logs. "

Clearly I fail the first test but pass the second.

>They could supply www.yahoo.de, for example, and it would pass
>your test, wouldn't it?

Indeed so, and I mentioned I use somebody else's HELO when using telnet
to a mail server. Obviously a lot of people don't go further than an
existence check. To be honest, I hadn't realised exim's HELO tests went
that far, and it's possible they didn't when I first configured it all
those years ago.

The sender_verify check is a useful one. I also ask for an ident
reply with a 30-second timeout, drop about twenty countries by code in
sender or HELO, make some attempt to spot DHCP-based PTRs and drop a
couple of thousand CIDR blocks, including most of APNIC. Oh, and a
couple of particularly 'difficult' foreign ISPs by name. Every little
helps, and of typically 1000-5000 bogus connections a day, about two get
through to the inbox, and that's with no content filtering at all. If
I'm using Thunderbird, then it will normally spot those two.

Here's the statistics for 24 hours to 07:30 today:

2011-07-10
count: 1791			[total]
Completed: 194			[genuine plus about 2]
rejected: 1342
timed: 948			[no reply to ident request]
country locally refused: 259	[in my blacklist]
syntactically: 2		[bad SMTP commands]
unwelcome ISP: 0		[none today]
locally blacklisted: 22		[IP address blacklist]
sender verify fail: 128		[invalid sender]
Generic: 78			[DHCP-derived PTR]
X-Host-Lookup-Failed: 806	[PTR or PTR-A verify fails]
synchronization error: 16	[more SMTP trouble]
Unrouteable: 12			[unknown recipient]

The numbers don't add up accurately because there are a few minor
categories I don't count, and the ones which give up during the ident
timeout don't get counted as rejected. A large number don't run ident
servers, but that's true of many legitimate mail servers. The good guys
will wait thirty seconds, however, and unfortunately, some of the
spammers also will.

Virtually all the spam is sent to unknown recipients, the last category
are the few which didn't fail other tests. Possibly the occasional one
is a mistyped name, but sadly I can't afford to send NDRs because
almost all will be NDR spam. I do actually check the reject file every
day for messages to the few legitimate recipients, but it's rare that I
see even one, and extremely rare when it's someone who should have
been allowed through. Maybe one of those a year, which is why I don't
like content filtering, which has a much poorer false positive rate.

There's no way of knowing how many of my emails go to exim4
installations, nor how they are configured. I do get the impression
from mail sending problems on a Microsoft forum I also use, that many
mail servers have similar configurations to mine. I'm not sure how far
the last two Exchange versions can go in terms of spam rejection, but
Exchange 2003 didn't have much built in. Microsoft are of course
pushing SPF instead.

-- 
Joe


Reply to: