Re: [exim] ot: rDNS + spam assassin

[Calum Mackay]

I'm a little late to this party, but…

Here's a couple of examples of well-known domains that "fail" my check:

  warn
condition = ${if and{{def:sender_host_address}{!def:sender_host_name}}\
  {yes}{no}}
add_header = X-Host-Lookup-Failed: Reverse DNS lookup failed for 
$sender_host_address (${if eq{$host_lookup_failed}{1}{failed}{deferred}})



cambridgejazz.org

thegreatcourses.com

localsecrets.com

mbna.co.uk


and that includes real user account emails, not just marketing spam.


apols for the late reply.

cheers,
calum.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Stefan Klatt]

Hi,

which kind of filter you use? Part of subject or list-id?
I think last is the best way to avoid such a situation.

Best regards

Stefan

Am 21.09.2016 um 10:55 schrieb Always Learning:
> On Wed, 2016-09-21 at 08:01 +0200, Jan Ingvoldstad wrote:
>
>> When I send something in private mail, it is extremely rude to post it
>> on-list. Please don't do that.
> Sorry, I did not notice it was private as it arrived in the general Exim
> circulars box.
>
> Have a nice day.
>
>

-- 
*CaC, Computer and Communication*
Inhaber Stefan Klatt
End-2-End Senior Network Consultant
Triftstrasse 9
60528 Frankfurt
Germany
USt-IdNr.: DE260461592

Tel.: +49-(0)172-6807809
Tel.: +49-(0)69-67808-900
Fax: +49-(0)69-67808-837
Email: stefan.kl...@cac-netzwerk.de
Profil: http://www.cac-netzwerk.de/profil



signature.asc
Description: OpenPGP digital signature
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Always Learning]

On Wed, 2016-09-21 at 08:01 +0200, Jan Ingvoldstad wrote:

> When I send something in private mail, it is extremely rude to post it
> on-list. Please don't do that.

Sorry, I did not notice it was private as it arrived in the general Exim
circulars box.

Have a nice day.


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Jan Ingvoldstad]

On Tue, Sep 20, 2016 at 10:55 PM, Always Learning  wrote:

...

When I send something in private mail, it is extremely rude to post it
on-list. Please don't do that.

-- 
Jan
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Always Learning]

> Would you share your acl file?

Privately yes, . you will also need the integrated external routines
(.php) that notify me of errors (via email) and instantly block (using
IP tables) abusers email addresses for about a month.

At the end of the week, I may have more time to organise that and create
some documentation explaining the system's logic, if you are interested.


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Wakko Warner]

Always Learning wrote:
> 
> On Tue, 2016-09-20 at 21:42 +0200, Jan Ingvoldstad wrote:
> 
> > You thereby come across as somewhat arrogant when presenting your
> > solution as _the_ solution, yet while skipping vital information that
> > you only shared in a fuzzy way when I pointed out challenges with what
> > you presented.
> 
> My Exim ACLs have been refined over about 8? years of experimentation,
> practise and errors. I do not claim 100% perfection but spam is about 2
> every 2 or 3 months and I have never used external spam databases. The
> ACL file is currently 38.3 KB.  

Would you share your acl file?

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Always Learning]

On Tue, 2016-09-20 at 21:42 +0200, Jan Ingvoldstad wrote:

> You thereby come across as somewhat arrogant when presenting your
> solution as _the_ solution, yet while skipping vital information that
> you only shared in a fuzzy way when I pointed out challenges with what
> you presented.

My Exim ACLs have been refined over about 8? years of experimentation,
practise and errors. I do not claim 100% perfection but spam is about 2
every 2 or 3 months and I have never used external spam databases. The
ACL file is currently 38.3 KB.  

My solution works for me. Other people operate with different criteria.
The presentation of ideas helps to expand one's knowledge of the
increasing availability of different solutions in probably the world's
most flexible MTA.

Robust resilience is what I have tried to achieve.

Constructive criticism is appreciated because it may alert me to imperfections 
or vulnerabilities.

Beste wensen,


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Always Learning]

On Tue, 2016-09-20 at 17:23 +0200, Jan Ingvoldstad wrote:

> > drop   condition  = ${lookup dnsdb{ptr=$sender_host_address} {0}{1} }
> >message= [SNA03] Rejected. Sender's IP address has no Host
> > name. \
> > MESS3
> >delay  = 15s

Hosted production domains have between 3 and 5 incoming MTAs (spanning 3
countries (UK is 1 country, not 4)) using different groups of multiple
DNS look-ups.

DWZ: No single point of failure.

> > drop   condition  = ${if and{{def:sender_host_address}{!
> > def:sender_host_name}} \
> >{yes}{no}}
> >message= [SNA04] Sender's Host has No Reverse DNS. \
> > Ask your technical experts to rectify the problem.

> This would also appear to fail if _you_ have a DNS problem.

Hetzelfde, the same

> I would recommend deferring the decision until later in the two above cases.

Users' safety and security is more important than receiving emails sent
from sloppily configured outgoing MTAs.  Why should we downgrade our
security to compensate for poor standards by those that do not care or
whom lack basic technical awareness ?  

> > drop   condition  = ${if match{${lc:$sender_host_name}} \
> >  {(broadband|client|customer|dsl|dyn|dynamic|home|host|static|user)(\\d|
> > \\.|\\-|ip)} \

   condition  = ${if match{${lc:$sender_host_name}}
{smarthost}{0}{1} }
#   note {0}{1} = non-match
   !condition = ${if match{${lc:$sender_host_name}} {mailhost} }
   !hosts = EXDIR/hosts.a13

> This would appear to eliminate several legitimate hosting providers which
> are not home internet connections, as you don't check on word boundaries,
> and even so, might match other legitimate services.

Exceptions can be added to EXDIR/hosts.a13. The current contents are:-

mail.host100.co.uk
*.pndsl.co.uk
*.smarthost.com
*.yorhost.net



Every rejection message, for these 3 examples, includes an alternative
email address which bypasses these checks - thus genuine senders blocked
(very few, estimated at 0.001%) can still contact us. Genuine senders
know users' telephone numbers thus there are 2 alternative methods to
report problems to us.

A daily Logwatch with a customised Exim section alerts us to potential
problems in addition to highlighting significant events. An instant
email alert notifies us of mail refusals in other ACLs.


Mvg,


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Jan Ingvoldstad]

On Tue, Sep 20, 2016 at 4:12 PM, Always Learning  wrote:

>
> On Mon, 2016-09-19 at 11:29 -0400, Dave Lugo wrote:
>
> > Yes, you should have some way to override the missing rDNS check.  But
> > rejecting on missing rDNS is mostly safe, in my opinion and experience.
>
> Agreed. Only positive action will reduce spam. Meekly accepting spam
> just encourages more spam.
>

While semi-blindly rejecting ham, will mostly lead to irritation among your
users and those they communicate with.

Striking a balance is difficult, but most users will be happy if they feel
they have some degree of control.

I see some challenges with your suggested filtering rules:


>
>
>
> drop   condition  = ${lookup dnsdb{ptr=$sender_host_address} {0}{1} }
>message= [SNA03] Rejected. Sender's IP address has no Host
> name. \
> MESS3
>delay  = 15s
>

This would appear to fail if _you_ have a DNS problem.


>
> drop   condition  = ${if and{{def:sender_host_address}{!
> def:sender_host_name}} \
>{yes}{no}}
>message= [SNA04] Sender's Host has No Reverse DNS. \
> Ask your technical experts to rectify the problem.
>

This would also appear to fail if _you_ have a DNS problem.

I would recommend deferring the decision until later in the two above cases.



>
>
> drop   condition  = ${if match{${lc:$sender_host_name}} \
>  {(broadband|client|customer|dsl|dyn|dynamic|home|host|static|user)(\\d|
> \\.|\\-|ip)} \
>

This would appear to eliminate several legitimate hosting providers which
are not home internet connections, as you don't check on word boundaries,
and even so, might match other legitimate services.

-- 
Jan
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Always Learning]

On Mon, 2016-09-19 at 11:29 -0400, Dave Lugo wrote:

> Yes, you should have some way to override the missing rDNS check.  But
> rejecting on missing rDNS is mostly safe, in my opinion and experience.

Agreed. Only positive action will reduce spam. Meekly accepting spam
just encourages more spam.

#
#   #
#  Start SMTP Connexion : section [A]   #
#   #
#

acl_check_connection:

accept  hosts = EXDIR/hosts.accept.a

drop   hosts  = EXDIR/hosts.amateur.spammer
   message= [SNA01] Your mailserver is on our Spammers list.
MESS3
   delay  = 30s

drop   hosts  = EXDIR/hosts.professional.spammer
   message= [SNA15] Your professional spam is prohibited. MESS3
   delay  = 30s

drop   condition  = ${lookup dnsdb{ptr=$sender_host_address} {0}{1} }
   message= [SNA03] Rejected. Sender's IP address has no Host
name. \
MESS3
   delay  = 15s

drop   condition  = ${if and{{def:sender_host_address}{!
def:sender_host_name}} \
   {yes}{no}}
   message= [SNA04] Sender's Host has No Reverse DNS. \
Ask your technical experts to rectify the problem. 

drop   condition  = ${if match{$sender_host_name} \
{^.*[0-9]+[\\-|\\.|_][0-9]+[\\-|\\.|_][0-9]+[\\-|\
\.|_]*.*}}
   !hosts = EXDIR/hosts.a8
   message= [SNA08] mail server host name not genuine? MESS3


drop   condition  = ${if match{${lc:$sender_host_name}} \
 {(broadband|client|customer|dsl|dyn|dynamic|home|host|static|user)(\\d|
\\.|\\-|ip)} \
  {1}{} }
   condition  = ${if match{${lc:$sender_host_name}}
{smarthost}{0}{1} }
#   note {0}{1} = non-match
   !condition = ${if match{${lc:$sender_host_name}} {mailhost} }
   !hosts = EXDIR/hosts.a13
   message= [SNA13] Your mail server's host name,
$sender_host_name, \
resembles a home Internet connection. MESS3


etc ..

[SNA13] = error code.
SN = 1 digit server (MTA) number
A = ACL section reference code
13 = routine with an ACL section

[2D16] = MTA 2, ACL section 'D', routine 16



-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[stef...@korbitec.com]

Nominally increased spam score is OK, as long as you're also checking a couple 
of DNS blacklists.

I only outright reject a remote host if it only presents an IP address, DNS 
lookup fails and blacklist check fails. Currently not receiving a lot of spam 
at all and rejection over 5000 messages.




 Original message 
From: John McMurray <j...@softsmart.co.za>
Date: 19/09/2016 17:52 (GMT+02:00)
To: Mike Tubby <m...@tubby.org>, exim-users@exim.org
Subject: Re: [exim] ot: rDNS + spam assassin

Hi Mike,

That's answers the second part of the question I initially asked, where
the reverse and forward domains don't exactly match for any of the
reasons you mention below.

What I am not sure about is who's problem is that? Is it mine on the
receiving end, or theirs? If they are using mismatched hosts is that not
something they are doing in a non standard way, and if so why should I
open myself up to more spam to accommodate them?

I'm not exactly a networking person so I don't know, just asking to learn..

Thanks again,

John




On 19/09/2016 17:43, Mike Tubby wrote:
>
>
> On 9/19/2016 4:29 PM, Dave Lugo wrote:
>> On Mon, 19 Sep 2016, Mike Tubby wrote:
>>>
>>> There is no 'law' that says your reverse DNS must work and its
>>> simply dangerous to use the heuristic no rDNS => High probability of
>>> SPAM.
>>
>> I respectfully disagree.  It's as dangerous as any other very effective
>> spam filtering method - high accuracy, low FPs.
>>
>> Yes, you should have some way to override the missing rDNS check. But
>> rejecting on missing rDNS is mostly safe, in my opinion and experience.
>>
>
> My point is that there's nothing in any of the RFCs that says your
> reverse DNS must work which is why we perform our checking against
> known block lists such as SpamHaus et. al.
>
> Our experience is that rDNS cannot be used reliably for several
> reasons that include:
>
> * multiple hosts behind load balancer
>
> * mis-match between exact host and generic host like
> "mx01a.megacorp.com" and "mx.megacorp.com"
>
> * internal hosts calling out through firewalls, eg. host
> MSEXCH01.internal.megacorp.com calls out through a firewall with a
> public IP that either reverses to "fw.megacorp.com" or in case of some
> organisations like the police is simply anonymous (no rDNS)
>
> hence our experience is that it is dangerous to attribute lack of
> correct rDNS to being SPAM, however YMMV  ;-)
>
> Mike
>
>


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Chris Siebenmann]

> That's answers the second part of the question I initially asked,
> where the reverse and forward domains don't exactly match for any of
> the reasons you mention below.
>
> What I am not sure about is who's problem is that? Is it mine on the
> receiving end, or theirs? If they are using mismatched hosts is that
> not something they are doing in a non standard way, and if so why
> should I open myself up to more spam to accommodate them?
>
> I'm not exactly a networking person so I don't know, just asking to
> learn..

 The simple answer is that it's your problem. There is no requirement
for a sending server to have either reverse DNS for their IP address
or an IP address that correlates to either the MAIL FROM domain/host
or the EHLO name that they use.

 Note that there are two sorts of requirements in SMTP in general. One
sort is merely written down in RFCs as a 'MUST' (not a 'SHOULD', that's
just advice), but in practice nothing fails to work if someone violates
it. The other sort is a practical one required for SMTP email to work,
either based on the RFCs or just based on what large, influential hosts
require in order to talk to you. Today, for example, a resolvable MAIL
FROM host/domain is a practical requirement in that if you try to send
email without it, the majority of mail servers will not accept your
email.

 There are some (or many) 'requirements' that are merely RFC
requirements, not practical ones. Unsurprisingly you will find many
perfectly good mail senders out there on the Internet violating these
RFC requirements, because nothing important actually enforces them
and so forces these sending hosts to pay attention. You can insist on
holding sending hosts to the letter of RFC requirements, but you should
not be surprised to find hosts violating them that send you legitimate
email and when this happens, the sending host may have absolutely no
interest in changing things to accomodate your strictness. (They may not
even notice.)

- cks

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Dave Lugo]

On Mon, 19 Sep 2016, Mike Tubby wrote:


My point is that there's nothing in any of the RFCs that says your reverse 
DNS must work which is why we perform our checking against known block lists 
such as SpamHaus et. al.




This may be true, but the reality of mail receiving is that sending IPs 
which are NXDOMAIN are generally safe to reject mail from.




Our experience is that rDNS cannot be used reliably for several reasons that 
include:


   * multiple hosts behind load balancer



Outbound hosts typically don't go through a load-balancer.


   * mis-match between exact host and generic host like "mx01a.megacorp.com" 
and "mx.megacorp.com"



I make no claims as to mismatches.  I do agree if you're going to to a 
fcrDNS check, it's best to be lenient if the names are different but are

in the same domain.



   * internal hosts calling out through firewalls, eg. host 
MSEXCH01.internal.megacorp.com calls out through a firewall with a public IP 
that either reverses to "fw.megacorp.com" or in case of some organisations 
like the police is simply anonymous (no rDNS)





See above.

hence our experience is that it is dangerous to attribute lack of correct 
rDNS to being SPAM, however YMMV  ;-)




There's a difference between lack of correct rDNS, and NXDOMAIN, and 
SERVFAIL.


The first, see my comments above.  The second, rejecting is relatively
safe.  The third, deferral is recommended.

--

Dave Lugo   dl...@etherboy.comLC Unit #260   TINLC
Have you hugged your firewall today?   No spam, thanks.

Are you the police?  . . . .  No ma'am, we're sysadmins.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Chris Siebenmann]

> Our experience is that rDNS cannot be used reliably for several reasons 
> that include:
> 
>  * multiple hosts behind load balancer
> 
>  * mis-match between exact host and generic host like 
> "mx01a.megacorp.com" and "mx.megacorp.com"
> 
>  * internal hosts calling out through firewalls, eg. host 
> MSEXCH01.internal.megacorp.com calls out through a firewall with a 
> public IP that either reverses to "fw.megacorp.com" or in case of some 
> organisations like the police is simply anonymous (no rDNS)

 To add another opinion, I think it's useful to distinguish between two
sorts of RDNS verification that I suspect people are doing.

 In the first sort, you simply verify that the IP address has valid RDNS
that verifies, which is to say that the IP has a PTR record and the name
in the PTR record lists the IP address as one of its A records (for
IPv4).

 In the more elaborate sort, you insist that the name the client EHLO'd
with matches the RDNS name (which you may or may not validate too). Or
maybe you insist that the name the client EHLO'd with has the connecting
IP as one of its A records (see, we're already getting complicated
here).

 Although I haven't run the numbers on our mail logs, I would expect
a certain amount of verification failures for the first sort of RDNS
verification and a *lot* of verification failures for the second sort.
People EHLO with all sorts of perfectly valid names that don't exactly
correspond to the IP address that is connecting to your server. Mike
Tubby listed some of the reasons for this above, and I'm sure there are
more.

 Overall I would expect there to be only a weak correlation between
this and spam level in general for arbitrary hosts. Of course if most
of your valid email comes from large hosts that do this 'right' (such
as GMail) and most contacts from random other IPs are sending spam, you
may observe a high (apparent) correlation between 'does not have RDNS'
and 'sends me spam'. But this is heuristic correlation, *not* causation,
and you should not be surprised if this correlation breaks down some day
(perhaps explosively, as you find a source that you very much want email
from that doesn't do this in what your particular setup considers right).

- cks

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[John McMurray]

Hi Mike,

That's answers the second part of the question I initially asked, where 
the reverse and forward domains don't exactly match for any of the 
reasons you mention below.


What I am not sure about is who's problem is that? Is it mine on the 
receiving end, or theirs? If they are using mismatched hosts is that not 
something they are doing in a non standard way, and if so why should I 
open myself up to more spam to accommodate them?


I'm not exactly a networking person so I don't know, just asking to learn..

Thanks again,

John




On 19/09/2016 17:43, Mike Tubby wrote:



On 9/19/2016 4:29 PM, Dave Lugo wrote:

On Mon, 19 Sep 2016, Mike Tubby wrote:


There is no 'law' that says your reverse DNS must work and its 
simply dangerous to use the heuristic no rDNS => High probability of 
SPAM.


I respectfully disagree.  It's as dangerous as any other very effective
spam filtering method - high accuracy, low FPs.

Yes, you should have some way to override the missing rDNS check. But
rejecting on missing rDNS is mostly safe, in my opinion and experience.



My point is that there's nothing in any of the RFCs that says your 
reverse DNS must work which is why we perform our checking against 
known block lists such as SpamHaus et. al.


Our experience is that rDNS cannot be used reliably for several 
reasons that include:


* multiple hosts behind load balancer

* mis-match between exact host and generic host like 
"mx01a.megacorp.com" and "mx.megacorp.com"


* internal hosts calling out through firewalls, eg. host 
MSEXCH01.internal.megacorp.com calls out through a firewall with a 
public IP that either reverses to "fw.megacorp.com" or in case of some 
organisations like the police is simply anonymous (no rDNS)


hence our experience is that it is dangerous to attribute lack of 
correct rDNS to being SPAM, however YMMV  ;-)


Mike





--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Mike Tubby]

On 9/19/2016 4:29 PM, Dave Lugo wrote:

On Mon, 19 Sep 2016, Mike Tubby wrote:


There is no 'law' that says your reverse DNS must work and its simply 
dangerous to use the heuristic no rDNS => High probability of SPAM.


I respectfully disagree.  It's as dangerous as any other very effective
spam filtering method - high accuracy, low FPs.

Yes, you should have some way to override the missing rDNS check. But
rejecting on missing rDNS is mostly safe, in my opinion and experience.



My point is that there's nothing in any of the RFCs that says your 
reverse DNS must work which is why we perform our checking against known 
block lists such as SpamHaus et. al.


Our experience is that rDNS cannot be used reliably for several reasons 
that include:


* multiple hosts behind load balancer

* mis-match between exact host and generic host like 
"mx01a.megacorp.com" and "mx.megacorp.com"


* internal hosts calling out through firewalls, eg. host 
MSEXCH01.internal.megacorp.com calls out through a firewall with a 
public IP that either reverses to "fw.megacorp.com" or in case of some 
organisations like the police is simply anonymous (no rDNS)


hence our experience is that it is dangerous to attribute lack of 
correct rDNS to being SPAM, however YMMV  ;-)


Mike


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[Dave Lugo]

On Mon, 19 Sep 2016, Mike Tubby wrote:


There is no 'law' that says your reverse DNS must work and its simply 
dangerous to use the heuristic no rDNS => High probability of SPAM.


I respectfully disagree.  It's as dangerous as any other very effective
spam filtering method - high accuracy, low FPs.

Yes, you should have some way to override the missing rDNS check.  But
rejecting on missing rDNS is mostly safe, in my opinion and experience.

--

Dave Lugo   dl...@etherboy.comLC Unit #260   TINLC
Have you hugged your firewall today?   No spam, thanks.

Are you the police?  . . . .  No ma'am, we're sysadmins.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Re: [exim] ot: rDNS + spam assassin

[John McMurray]

Hi Mike,

We actually do do many of those tests and you're right, most of what 
would otherwise come through gets blocked...


My reasoning for using rDNS with such a high trigger is that its such an 
easy fix that I think that any mail server which doesn't implement it is 
just being a bit lazy (disclaimer: I don't often know what I'm talking 
about so there could well be valid reasons for not having rDNS set the 
way I think it should be set)..


Thank you for your sample config, I'll definately take a closer look at 
it in a day or two and I'm sure I'll be pinching something from it to 
use in my own config..


Regards,

John


On 19/09/2016 17:16, Mike Tubby wrote:
I think the problem is that you're relating an IP/DNS issue to a SPAM 
identification technology.


There is no 'law' that says your reverse DNS must work and its simply 
dangerous to use the heuristic no rDNS => High probability of SPAM.


You would probably be better served using extensive checking at:

1. initial TCP connection, then
2. at HELO/EHLO greeting, then
3. at the MAIL command


Using this approach we block unwanted senders (unwanted connects) 
because they are identified as such, we block spammers that use broken 
protocol like attempting to send before they say HELO or EHLO.  We 
block spammers and systems that use bare words like "HELO COMPUTER" or 
dotted quads like "HELO 1.2.3.4".


By the time an email gets as far as SpamAssassin on our systems its 
already been through 30+ other pre-checks which are more efficient and 
more accurate than providing a high weighting to something that can 
give a false positive.



Mike



Here's some config to consider ...


begin acl

###
### acl_check_connect: This access control list checks the inbound
### connection against a number of DNS based block lists
###

acl_check_connect:
warnlogwrite = CONNECT: New connection from 
$sender_host_address:$sender_host_port -> 
$received_ip_address:$received_port

set acl_m5 = 0

#
# accept the connection here if it is on MSA port 587
#
accept  condition = ${if eq{$interface_port}{587}{1}{0}}
set acl_m5 = 1
logwrite = CONNECT: Host $sender_host_address allowed 
on MSA/MUS port 587 - connect checks skipped


#
# check and accept if host is white-listed in our database
#
accept  hosts = +whitelist_dnsbl_hosts
logwrite = CONNECT: Host $sender_host_address is 
whitelisted in database, RBL checks skipped


#
# see if its whitelisted at junkmailfilter.com - only warn
#
warndnslists = 
hostdomain.junkemailfilter.com=127.0.0.1/$sender_host_name
logwrite = CONNECT: Host name $sender_host_name 
whitelisted at $dnslist_domain : $dnslist_value


#
# check if host white-listed at DNSWL.ORG
#
accept  dnslists = list.dnswl.org&0.0.0.2
logwrite = CONNECT: Host $sender_host_address 
whitelisted at $dnslist_domain : $dnslist_value


#
# checks via various DNS Block Lists. These could be condensed 
into a single check with a
# multi-part dnslists = ... entry but specifying them 
separately gives us fine-grained
# control.  We can log each by name and can enable/disable 
them.  Enable by setting them to
# 'drop' (connection refused) and disabled them by setting to 
'warn' (log entry only)

#

# SpamHaus.org
dropdnslists = zen.spamhaus.org
logwrite = CONNECT: Reject: $sender_host_address 
according to: $dnslist_domain : $dnslist_value



# Sorbs.net
warndnslists = dnsbl.sorbs.net
logwrite = CONNECT: Reject: $sender_host_address 
according to: $dnslist_domain : $dnslist_value



# SpamCop.net
warndnslists = bl.spamcop.net
log_message = CONNECT: Warning: $sender_host_address 
according to: $dnslist_domain : $dnslist_value



# AbuseAt.org
warndnslists = cbl.abuseat.org
log_message = CONNECT: Warning: $sender_host_address 
according to: $dnslist_domain : $dnslist_value


#
# accept the rest
#
accept  logwrite = CONNECT: Accepting connection from: 
$sender_host_address - not blocked by any RBL



###
### acl_start_tls: This access control list reports client used START TLS
###

acl_start_tls:

accept  logwrite = CRYPTO: Client 
$sender_host_address:$sender_host_port issued STARTTLS





###
### acl_check_helo: check the HELO/EHLO
###

acl_check_helo:

#
# accept for relay_from_hosts
#
accept  condition = ${if 
match_domain{$sender_helo_name}{$+relay_from_hosts}{true}{false}}
logwrite = HELO: Accepted HELO/EHLO $sender_helo_name 
from remote host: $sender_host_address ${if def:sender_host_name 
{($sender_host_name) }} in hostlist relay_from_hosts

Re: [exim] ot: rDNS + spam assassin

[Mike Tubby]

I think the problem is that you're relating an IP/DNS issue to a SPAM 
identification technology.


There is no 'law' that says your reverse DNS must work and its simply 
dangerous to use the heuristic no rDNS => High probability of SPAM.


You would probably be better served using extensive checking at:

1. initial TCP connection, then
2. at HELO/EHLO greeting, then
3. at the MAIL command


Using this approach we block unwanted senders (unwanted connects) 
because they are identified as such, we block spammers that use broken 
protocol like attempting to send before they say HELO or EHLO.  We block 
spammers and systems that use bare words like "HELO COMPUTER" or dotted 
quads like "HELO 1.2.3.4".


By the time an email gets as far as SpamAssassin on our systems its 
already been through 30+ other pre-checks which are more efficient and 
more accurate than providing a high weighting to something that can give 
a false positive.



Mike



Here's some config to consider ...


begin acl

###
### acl_check_connect: This access control list checks the inbound
### connection against a number of DNS based block lists
###

acl_check_connect:
warnlogwrite = CONNECT: New connection from 
$sender_host_address:$sender_host_port -> 
$received_ip_address:$received_port

set acl_m5 = 0

#
# accept the connection here if it is on MSA port 587
#
accept  condition = ${if eq{$interface_port}{587}{1}{0}}
set acl_m5 = 1
logwrite = CONNECT: Host $sender_host_address allowed 
on MSA/MUS port 587 - connect checks skipped


#
# check and accept if host is white-listed in our database
#
accept  hosts = +whitelist_dnsbl_hosts
logwrite = CONNECT: Host $sender_host_address is 
whitelisted in database, RBL checks skipped


#
# see if its whitelisted at junkmailfilter.com - only warn
#
warndnslists = 
hostdomain.junkemailfilter.com=127.0.0.1/$sender_host_name
logwrite = CONNECT: Host name $sender_host_name 
whitelisted at $dnslist_domain : $dnslist_value


#
# check if host white-listed at DNSWL.ORG
#
accept  dnslists = list.dnswl.org&0.0.0.2
logwrite = CONNECT: Host $sender_host_address 
whitelisted at $dnslist_domain : $dnslist_value


#
# checks via various DNS Block Lists. These could be condensed 
into a single check with a
# multi-part dnslists = ... entry but specifying them 
separately gives us fine-grained
# control.  We can log each by name and can enable/disable 
them.  Enable by setting them to
# 'drop' (connection refused) and disabled them by setting to 
'warn' (log entry only)

#

# SpamHaus.org
dropdnslists = zen.spamhaus.org
logwrite = CONNECT: Reject: $sender_host_address 
according to: $dnslist_domain : $dnslist_value



# Sorbs.net
warndnslists = dnsbl.sorbs.net
logwrite = CONNECT: Reject: $sender_host_address 
according to: $dnslist_domain : $dnslist_value



# SpamCop.net
warndnslists = bl.spamcop.net
log_message = CONNECT: Warning: $sender_host_address 
according to: $dnslist_domain : $dnslist_value



# AbuseAt.org
warndnslists = cbl.abuseat.org
log_message = CONNECT: Warning: $sender_host_address 
according to: $dnslist_domain : $dnslist_value


#
# accept the rest
#
accept  logwrite = CONNECT: Accepting connection from: 
$sender_host_address - not blocked by any RBL



###
### acl_start_tls: This access control list reports client used START TLS
###

acl_start_tls:

accept  logwrite = CRYPTO: Client 
$sender_host_address:$sender_host_port issued STARTTLS





###
### acl_check_helo: check the HELO/EHLO
###

acl_check_helo:

#
# accept for relay_from_hosts
#
accept  condition = ${if 
match_domain{$sender_helo_name}{$+relay_from_hosts}{true}{false}}
logwrite = HELO: Accepted HELO/EHLO $sender_helo_name 
from remote host: $sender_host_address ${if def:sender_host_name 
{($sender_host_name) }} in hostlist relay_from_hosts



#
# check for single word greeting messages like "HELO COMPUTER"
#
denycondition = ${if match {$sender_helo_name} {\\.} {no}{yes}}
message = Your HELO/EHLO greeting ($sender_helo_name) 
is a single word. \
According to RFC2821 you must use your 
fully-qualified domain-name. \
Please fix your configuration if you want to 
talk to us
logwrite = HELO: HELO/EHLO was not a FQDN : 
$sender_helo_name from $sender_fullhost


#
# check for raw IP address in greeting like "HELO 1.2.3.4"
#
denycondition = ${if 

[exim] ot: rDNS + spam assassin

[John McMurray]

Hi everyone,

I hope its ok to ask an off topic question in this group. I ask here 
because even though it is off topic its obviously closely related and 
I'd love to hear what your thoughts are on the following:


In my exim servers I assign a very high spam assassin score to incoming 
mail servers without rDNS (RDNS_NONE = 4.5).


This has worked well for me blocking a fair amount of spam (or rather, 
pushing the overall score high enough to block the spam).


I have a client on my servers who cannot receive mail from one of their 
contacts. It turns out that this sender's forward and reverse records 
don't match exactly, eg:


mailsecurity-01.example.com. => 1.2.3.4

but

dig -x 1.2.3.4 => gateway.example.com.


So my question(s) are basically:

1) am I being too over the top assigning such high spam assassin to 
incoming mail without valid rDNS?


2) Should it be considered valid if the tld matches but not the sub 
domain as in the example above (and if so any pointers on how to achieve 
that in exim)?



Thank you,

John McMurray

j...@softsmart.co.za


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/