On Sun, 10 Jul 2011 01:47:19 +0200 lee <l...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110710153916.7a70f...@jresid.jretrading.com