Re: [exim] using different ports for different mx preference…

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] using different ports for different mx preferences
Jason_Meers wrote:
> Hi all,
>
> This is a new post quoting a section of a previous post.
>
> -snip-
> Background:
> The idea is to develop a config that could determine which MX record had
> been used to make the initial connection (by getting the firewall to
> forward the SMTP conversation to different ports on the same server,
> based on the IP address the connection initially came in on).
> This would avoid having to have a dedicated box and dedicated config for
> each MX preference.
> -snip-
>
>
> I'm seeing a lot of junk-mail deliberately going for the lower
> preference MX records first (by lower preference I mean MX records with
> a higher numerical value than the others). The thought is to be more
> strict/thorough about checking connections that are initially made to
> the "wrong" MX (because I don't expect this of a "genuine" properly
> configured MTA).
>
> Is it acceptable to just dump connections that make no attempt to follow
> the RFC's and go directly for the lower pref MX's.


Not really.... see below...

> I have 5 other boxes
> (in separate locations) that _should_ have been tried before anyone
> would have a valid reason to connect directly to the lowest pref box.
>
> Is anybody else already doing this?
> Does it work for you?
>
> Thanks
> Jason_Meers
>
>


Mark Perkel has posted a great deal about his methodology of using
'bait' MX cleverly to trap/divert spam.

Personally, I think that approach just 'plays' with spam sources that
can easily be blocked by simpler means (lack of a PTR RR and/or dynamic
IP RBL-hit at the top of *my* list. YMMV).

But the larger issue is that if you *publish* a DNS entry for an MX -
regardless of its priority - then you should damn well be prepared to
accept 'normal' traffic on it.

ELSE - don't publish it, as you are contributing to breaking
RFC-mandated behaviour for the many who *need* backup MX to function as
expected.

Spam is by no means the only driver for selecting a lower-priority MX,
and two wrongs don't make a right - complaints or lack therof
notwithstanding.

Bill