Spammers sending based on A record, not MX

[pierceddude]

I'm having some issues with receiving mail that is not being routed based on MX records. A customer has opted to use a third party source to filter mail prior to being sent to my server. We have changed the MX record and in over a week we are still seeing messages being sent directly to the server without going through the third party source specified in the MX record. Legitimate, nonspam email is showing the correct headers with the appropriate servers.

The only reason I can find for this is if a spammer attempts to send mail based on the A record for the domain before trying the MX record, that message is accepted for the user completely bypassing the spam filtering.

I'm somewhat savvy with understanding the concepts behind smtp but not so savvy with exim.conf tweaks and would prefer to make changes that would not be overwritten by CPanel on updates.

I considered going a firewall option blocking port 25 on all but one port and changing the DNS zones to route mail to one particular IP address. But that also would involve asking all my users to change their SMTP server in their mail clients.

Does anyone have any suggestions on how to force mail to be routed based on MX for domains that want mail filtered outside of the server?

 

[chirpy]

Part of the problem is that the SMTP protocol allows for the use of the A record if there's either no MX record or if the server at the end of the MX record does not respond. It's a fail-safe to ensure email delivery, but can cause the problems you are seeing when using third party email processors - especially if their service has any problems.

You can configure exim to only receive on one IP address (and change your users DNS zones as you say). Since listening and sending are different, you can still allow sending on any IP address and so avoid the user client issue.

However, doing so could cause your client using the third-party processor to lose legitimate email being delivered to the last route of hope (the A record) if there are problems contacting the MX record.

Such are the problems of messing around with smart routers.

 

[pierceddude]

I see the logic behind reverting to the A record but it seems a bit misplaced. Especially in CPanel environment where the A record and MX record are all pointing to the same place. If the server referenced by the MX record is not available, then neither will the server reference by the A record.

In this particular case, it's obvious it isn't a fail safe revert to the A record for delivery after not being able to reach the MX host. Consistantly all of the messages received directly to the A record was Spam. That would make me tend to believe it was a deliberate attempt to send to the A record without even looking at the MX record.

I'm a bit confused about your comment about listening and sending are different. SMTP is used by both a remote machine as well as an end user sending mail from their mail client. If I restrict access to a particular IP then not only do all the remote mail servers have to connect to that IP (by way of the MX record) but also all of the client machines would need to make reference to the new IP by way of newmailserver.domain.com to handle their outgoing mail.

I'm looking for a solution that doesn't involve changes to a client configuration. It seems feasible in theory to have exim refuse connections for particular domains unless the originate from a specified host (in this case the third party spam filter) or from a host authorized to relay (my users)

 

[pierceddude]

I was doing a little research and thought I'd clarify some of what you mentioned about the SMTP protocol, MX records and A records. RFC 2821 actually states that if an MX records are available but none of them are usable, it must be reported as an error. It must not use the implicit MX rule and try to send to the A record.


Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.

 

[chirpy]

I've thought about this a bit more and there is actually quite a simple solution. Since you know where the email for the domain should be coming from (the 3rd party mail relays) then you should be able to construct an exim ACL that simply tests whether the connecting host for a RCPT address for that domain is one in a predefined list.

Have a look at exim ACL's over here:
http://www.exim.org/exim-html-4.40/doc/html/spec_38.html#CHAP38