greylisting

[blu at vl.com (Tom Metro)]

James Kramer wrote:
> I set up greylisting for my mail server and recall once reading that
> it is possible to set up an effective spam blocker by changing the top
> MX record on the dns server to point to a bad address.
...
> Has anyone tried this?

I've heard of this as well, but have not tried it.

I think the primary MX needs to be more than just a "bad address." It 
probably needs to be pointing to a server running a specialized daemon 
that always responds with a 4xx temporary failure code (like a "421 
Service not available"). The theory being it has a similar effect on 
spam software that has inadequate error handling and no capacity to 
queue messages.

However, it isn't clear from RFC2821 that a standards compliant client 
should try a lower priority MX upon receiving a protocol error:

ftp://ftp.isi.edu/in-notes/rfc2821.txt

    5. Address Resolution and Mail Handling
[...]
    When the lookup succeeds, the mapping can result in a list of
    alternative delivery addresses rather than a single address, because
    of multiple MX records, multihoming, or both.  To provide reliable
    mail transmission, the SMTP client MUST be able to try (and retry)
    each of the relevant addresses in this list in order, until a
    delivery attempt succeeds.

It never really addresses the nature of the conditions that warrant 
retrying. A refused connection or an otherwise failed attempt to connect 
to the SMTP server is the obvious implied condition that warrants a 
retry using the next MX.

Similar the section on "Sending Strategy" doesn't say when the client 
should consult the MX list again, but does say:

    4.5.4.1 Sending Strategy
[...]
    A client SHOULD keep a list of hosts it cannot reach and
    corresponding connection timeouts, rather than just retrying queued
    mail items.

Which isn't too helpful, but maybe suggests that the client shouldn't 
immediately retry an MX host it previously tried and knew failed.


It does say that for multi homed hosts, it is the responsibility of DNS 
to return the list of addresses in the preferred order, and the client 
should treat them like an ordered list of MXs.

So I could see setting up DNS like:

mail	MX	0	smtp.example.com.
smtp	A	256.256.256.256
smtp	A	1.2.3.4

so that clients get two IP addresses, with the first one always being 
bogus. That probably has a good chance of fouling spam software without 
impacting standards compliant mailers.

Although this is essentially what you suggested in the first place. But 
the difference is that it depends on a slightly more obscure aspect of 
the protocol. It wouldn't surprise me if spam software was typically 
smart enough to anticipate non-responsive MXs and skip over them. (Some 
spam software intentionally targets lower priority MXs thinking that 
they'll have weaker spam defenses and offer a back door.) So to work I'd 
expect you'd either need to temp fail after entering the protocol 
handshake (as suggested above), or do something else, like pretending to 
be multi homed.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.