headers
Matt Simerson | 14 Jun 2012 00:03
Gravatar

new plugin: helo


https://github.com/smtpd/qpsmtpd/pull/29

I've been running it on my server for a week in RFC policy mode.  I knew from hours of watching logs that it would
be effective, but measuring it was still surprising and delightful.  Of the 10% of connections that make it
past the dnsbl and karma tests, another 50% are rejected by these HELO tests.  Of those 50%, more than 95% are
connections from Windows (most Win 7) hosts where the DNS bears no resemblance to the HELO hostname
offered.  

Since expanding the no_matching_dns test (earlier today), I have yet to see a single false positive from
that test. While I'm still not using that as a condition for rejection, it may now be good enough to enforce. 

Matt

NAME
    helo - validate the HELO message presented by a connecting host.

DESCRIPTION
    Validate the HELO hostname. This plugin includes a suite of optional
    tests, selectable by the *policy* setting. The policy section details
    which tests are enforced by each policy option.

    This plugin adds an X-HELO header with the HELO hostname to the message.

    Using *policy rfc* will reject a very large portion of the spam from
    hosts that have yet to get blacklisted.

WHY IT WORKS
    The reverse DNS of the zombie PCs is out of the spam operators control.
    Their only way to get past these tests is to limit themselves to hosts
(Continue reading)

Permalink | Reply |
headers
Charlie Brady | 15 Jun 2012 15:27
Picon
Picon

Re: new plugin: helo


On Wed, 13 Jun 2012, Matt Simerson wrote:

> https://github.com/smtpd/qpsmtpd/pull/29

 Make sure the HELO hostname has an A or AAAA record that matches the senders
 IP address, and make sure that the senders IP has a PTR that resolves to the
 HELO hostname.

 This might sound pedantic, but since time immemorial, having matching DNS is
 a minimum standard expected, and frequently required, of mail servers.

I think that "time immemorial" is hyperbole, "a minimum standard" is vague 
(expected by whom?) and "frequently required" is inaccurate - I think this 
is infrequently required by mail servers - it certainly isn't mandated by 
any RFC, or enforced by qpsmtpd.org (or you wouldn't be reading this 
message).
Permalink | Reply |
headers
Charlie Brady | 15 Jun 2012 15:44
Picon
Picon

Re: new plugin: helo


On Wed, 13 Jun 2012, Matt Simerson wrote:

> https://github.com/smtpd/qpsmtpd/pull/29

I consider this statement to be troublesome also:

 Per RFC 2821, the HELO hostname must be the FQDN of the sending server or 
 address literal. 

RFC 2821 doesn't say "must". It says neither should nor must, but simply 

 The argument field contains the fully-qualified domain name of the SMTP 
 client if one is available.

Mail servers can certainly be expected to have a FQDN. But expecting them 
to have *only one* FQDN may be too tight a constraint.

Is there a definition of canonical FQDN? Is the canonical FQDN anything 
other than just the name defined by whoever manages reverse DNS? In my 
experience, reverse DNS is frequently managed (or, frequently, not 
managed) by an ISP, not by the admin of the mail server.
Permalink | Reply |
headers
Matt Simerson | 15 Jun 2012 19:18
Gravatar

Re: new plugin: helo


On Jun 15, 2012, at 6:44 AM, Charlie Brady wrote:

> On Wed, 13 Jun 2012, Matt Simerson wrote:
> 
>> https://github.com/smtpd/qpsmtpd/pull/29
> 
> I consider this statement to be troublesome also:
> 
> Per RFC 2821, the HELO hostname must be the FQDN of the sending server or 
> address literal. 

-Per RFC 2821, the HELO hostname must be the FQDN of the sending server or an
+Per RFC 2821, the HELO hostname is the FQDN of the sending server or an

s/must be/is/

> RFC 2821 doesn't say "must". It says neither should nor must, but simply 
> 
> The argument field contains the fully-qualified domain name of the SMTP 
> client if one is available.

In that very same paragraph, and the preceding one, the RFC spells out the purpose of the HELO hostname,
which is to identify the sending system. I believe that's why the RFC writers chose to use the definite
article when defining the FQDN, rather than saying "a FQDN," or "any FQDN," or "anything that suits your
fancy."  The purpose is explicit, to identify the sending system.

> Mail servers can certainly be expected to have a FQDN. But expecting them 
> to have *only one* FQDN may be too tight a constraint.
(Continue reading)

Permalink | Reply |
headers
Charlie Brady | 15 Jun 2012 21:32
Picon
Picon

Re: new plugin: helo


On Fri, 15 Jun 2012, Matt Simerson wrote:

> > In my experience, reverse DNS is frequently managed (or, frequently, not 
> > managed) by an ISP, not by the admin of the mail server.
> 
> In my experience, every ISP that provides clients with dedicated IPs 
> also provides the client with the ability to manage the reverse DNS for 
> them.

My ISP (a smallish not-for-profit affair) claims to be unable to do that. 
I've heard of and seen other ISPs which fail also. I agree that most ISPs 
offer this service. A single exception is sufficient to say this can't be 
guaranteed.

> Either via a support request or automated means.  I did when I 
> owned my ISP in the early 90s, and every ISP and hosting provider I've 
> ever worked for or with since does as well. The good providers even 
> provide rwhois on the delegated IP space and automatically populate it 
> with the clients billing data. (see RFC 1941).

Yes, good providers do that.
Permalink | Reply |
headers
Matt Simerson | 15 Jun 2012 23:34
Gravatar

Re: new plugin: helo


On Jun 15, 2012, at 12:32 PM, Charlie Brady wrote:

> On Fri, 15 Jun 2012, Matt Simerson wrote:
> 
>>> In my experience, reverse DNS is frequently managed (or, frequently, not 
>>> managed) by an ISP, not by the admin of the mail server.
>> 
>> In my experience, every ISP that provides clients with dedicated IPs 
>> also provides the client with the ability to manage the reverse DNS for 
>> them.
> 
> My ISP (a smallish not-for-profit affair) claims to be unable to do that. 
> I've heard of and seen other ISPs which fail also. I agree that most ISPs 
> offer this service. A single exception is sufficient to say this can't be 
> guaranteed.

Why does this matter?  Having a custom FQDN that you can manage is not required by RFC 2821 or my helo plugin.

The RFC requires that you use the FQDN (and presumably matching rDNS) that's assigned to your IP as the HELO
hostname.  If your smallish ISP isn't capable of managing DNS properly, and you don't have a meaningful
FQDN, then you use an address literal. 

The RFC tests in the new helo plugin are VERY low bars to clear. In the default 'lenient' mode, no DNS
validation is performed at all. In RFC mode, if you present a HELO hostname, then that hostname must have
SOME kind of working DNS. It doesn't even have to be a match unless 'policy strict' is chosen. 

Of the 40,494 messages in my logs, 22,418 of them have invalid HELO hostnames and 158 messages are using
address literals. Almost half (67) of the literals are from valid users of my mail server.  Which is why I
don't block address literals. But I can safely do so now without causing my users problems because of the
(Continue reading)

Permalink | Reply |

Gmane