Re: [exim] verify_sender - Do's and Dont's version 1

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Russell Robinson
Dátum:  
Címzett: exim-users
Régi témák: Re: [exim] verify_sender
Tárgy: Re: [exim] verify_sender - Do's and Dont's version 1
Hi,

Thanks so much to all who have replied on this topic!

I've attempted to digest all points made, and I've come up with a (hopefully)
non-controverisal and accurate list of Do's and Dont's in accepting
connections.

Clearly, this is extremely complex and there just doesn't seem to be a
definitive (and correct) list of what to do to safely block spammer
connections anywhere on the net (I've been looking!).

Even the "standards" people have little or nothing to say on this topic.

Amongst those who replied to this topic, there are differences of opinion, and
maybe some inaccurate or incorrect methods.

My version 1 of the list is below.

Please respond with additions or changes, and maybe this can become some sort
of accepted or definitive list.

A corresponding set of ACL's would be a good addition.

Notes about Safely Blocking Email with Exim
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Version 1 17-May-2010
~~~~~~~~~~~~~~~~~~~~~

From the "verify_sender" subject posted to exim-users.org.

Do Not...
~~~~~~~~~

1.  perform sender verification callouts.  This means don't attempt to verify
    the email address of the sender.  These queries can cause backlisting. The
    response from such a query is also unreliable.


2.  use auto-responders/out-of-office replies.  This of course implies
    don't use Challenge-Response systems after receiving the email from
    Exim.


3.  check that the IP connecting has a PTR record that is trackable to
    an MX record.  It's perfectly legit for sending servers to be
    completely different to MX servers.  However, see DO#5 below.


Do...
~~~~~

1. perform sender domain verification.

2. reject email at connection where possible (acl_smtp_connect).

3. check that the connecting server is legit

4. as much rejection in acl's, none in router/transport sets.

5.  check that the IP connecting has a PTR record that is trackable to
    an A record for the FQDN they claimed. You have to do sub-domain
    matching (e.g.  *.amazon.com) for this to make sense.


6.  reject a connection whose IP doesn't have a PTR record.  Even
    though this is valid according to the RFCs, in practice almost all
    legitimate SMTP connections can be assumed to have PTR records in the
    DNS. A whitelist might be required for some exceptions.


    An exception might be one's own user community, connect from ISP's.
    (These can be accepted by explicit authentication or some other
    method.)


7.  assume commercial spammers (those who aren't trying to hide) will
    have valid DNS entries and they must be rejected using other means
    (e.g. RBL, LBL).



--
Russell Robinson (russellr@???)