Dealing with MXlo stupidity - any ideas ?

[mrlu...@gmail.com]

I am looking for ideas on how to deal with the insanity that MXlo is causing for me.

"MXlo means DNS resource records of the MX type that have a value of localhost. The name comes from combining the MX from Mail eXchange and the lo abbreviation for a loopback networking interface, and is an anti-spam technique that is growing in popularity with network administrators who manage a large number of unused legacy domain names."

We send mail on behalf of our customers (A) to their customers (B).

If (A) gets the email address for (B) wrong and the resultant email address is for a domain that is parked with a parking site (e.g. Sedo Parking) that uses MXlo the DSN my sytem sends to (A) reports that my system is miconfigured.

e.g.

554 5.0.0 MX list for abhotel.com. points back to myserver.com.au
554 5.3.5 Local configuration error

This makes me look bad to (A) as they think I have a setup problem which I do not.

This is caused by the MX record for the domain being as follows:

dig mx abhotel.com

;; QUESTION SECTION:
;abhotel.com. IN MX

;; ANSWER SECTION:
abhotel.com. 3600 IN MX 0 localhost.

;; AUTHORITY SECTION:
abhotel.com. 172800 IN NS ns1.sedoparking.com.
abhotel.com. 172800 IN NS ns2.sedoparking.com.

;; ADDITIONAL SECTION:
localhost. 10800 IN A 127.0.0.1
localhost. 10800 IN AAAA ::1
ns1.SEDOPARKING.com. 97644 IN A 209.200.164.69
ns2.SEDOPARKING.com. 97644 IN A 209.200.165.74

;; Query time: 500 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Mon Sep 05 12:55:58 AEST 2016
;; MSG SIZE rcvd: 209

Thanks for violating two RFCs for every domain parked by Sedo...

Can anyone suggest a way I can "fix" this or am I doomed ?

[Claus Aßmann]

> abhotel.com. 3600 IN MX 0 localhost.

> abhotel.com. 172800 IN NS ns1.sedoparking.com.
> abhotel.com. 172800 IN NS ns2.sedoparking.com.

> Can anyone suggest a way I can "fix" this or am I doomed ?

Some suggestions:

Take a look at badmx and use it also for check_rcpt.

Write your own DNS map to look up NS, check whether it matches
sedoparking.com
and reject those addresses.


--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

[mrlu...@gmail.com]

Thanks for the advice.

[ska]

On Monday, September 5, 2016 at 5:00:32 AM UTC+2, mrlu...@gmail.com wrote:
> I am looking for ideas on how to deal with the insanity that MXlo is causing for me.

> ;; ANSWER SECTION:
> abhotel.com. 3600 IN MX 0 localhost.

I'm using a custom milter to reject those recipients.

MIMEDefang is a generic milter you can code a custom handler with. For your situation, it seems exaggerated, though.

[mrlu...@gmail.com]

On Monday, September 5, 2016 at 11:40:03 PM UTC+10, Claus Aßmann wrote:
>
> Take a look at badmx and use it also for check_rcpt.

Sorry for taking soooo long to get back to this problem...

Would this be best done using Local_check_rcpt ?

Could someone point me at an example of how to correctly do this as I have zero experience is creating rulesets ?

[Claus Aßmann]

> Would this be something like what I need ?

> LOCAL_RULESETS
> SLocal_check_rcpt
> R$* $: $1 $| $>"BadMX" $1

That is very unlikely... check the fine documentation
what is expected to be returned by [Local_]check_rcpt.

You are referring to a usenet posting which is "very" old -- usenet
isn't some "forum" but (almost all of) its servers "expire" postings
after a fairly short amount of time.
Hence it might be a good idea to restate the problem you are trying
to solve.

PS: also take a look at
http://www.sendmail.org/~ca/email/chk-dbg.html

[mrlu...@gmail.com]

After some more reading and experimenting I think this works but I will be doing more testing...

Assuming you have defined FEATURE(`badmx') the following appears to do what I want...

LOCAL_RULESETS
SLocal_check_rcpt
R<$+@$+> $: <$1@$2> $| $>BadMX $2

[mrlu...@gmail.com]

On Friday, August 18, 2017 at 5:01:17 PM UTC+10, mrlu...@gmail.com wrote:
> Assuming you have defined FEATURE(`badmx') the following appears to do what I want...

except it causes problems with legitimate email going to recipients whose MX lookups suffer timeouts which are then treated as errors.

I am giving up on this for now.

[Claus Aßmann]

[Using BadMX for other purposes]

> except it causes problems with legitimate email going to recipients whose MX lookups suffer timeouts which are
> then treated as errors.

That should only be a temporary error:

R<MX><$+><:$*<TEMP>:><$*> $#error $@ 4.1.2 $: "450 MX lookup failure for " $1

If that causes problem in your case, you could make a copy of the
ruleset and ignore TEMP failures (depending on your goal).