[Discuss] Exim sender_verify issue?

Peter Jalajas pjalajas at tebuco.com
Fri Jun 14 08:24:05 EDT 2013


Hi Rich,

Thanks for your reply.

I stumbled some exim command-line fu, and ran this:
# exim -d-all+dns+resolver -bvs sender at domain.org
...
DNS lookup of domain.org (MX) succeeded
DNS lookup of ASPMX.L.GOOGLE.COM (AAAA) succeeded
DNS lookup of ASPMX.L.GOOGLE.COM (A) succeeded
DNS lookup of ALT1.ASPMX.L.GOOGLE.COM (AAAA) succeeded
DNS lookup of ALT1.ASPMX.L.GOOGLE.COM (A) succeeded
DNS lookup of ALT2.ASPMX.L.GOOGLE.COM (AAAA) succeeded
DNS lookup of ALT2.ASPMX.L.GOOGLE.COM (A) succeeded
DNS lookup of ASPMX4.GOOGLEMAIL.COM (AAAA) succeeded
DNS lookup of ASPMX4.GOOGLEMAIL.COM (A) succeeded
DNS lookup of ASPMX2.GOOGLEMAIL.COM (AAAA) succeeded
DNS lookup of ASPMX2.GOOGLEMAIL.COM (A) succeeded
DNS lookup of ASPMX3.GOOGLEMAIL.COM (AAAA) succeeded
DNS lookup of ASPMX3.GOOGLEMAIL.COM (A) succeeded
DNS lookup of ASPMX5.GOOGLEMAIL.COM (AAAA) succeeded
DNS lookup of ASPMX5.GOOGLEMAIL.COM (A) succeeded

So, in the end, I think the problem is that, at least on my hosted server,
exim sender_verify only queries one sender nameserver for an MX record, and
if that query fails, the incoming email is rejected.   We've now turned off
sender_verify and will now see how good it was anyway at stopping spam
(reviews of sender_verify on the web are mixed).

(Me thinking a little more about it, exim querying for an MX record is
perhaps a little odd, because MX records are intended to inform _senders_
about where to _send_ email _to_, not necessarily to inform anyone on where
email might be legitimately coming _from_; hence, SPF, DKIM, and DMARC.)

Thanks again, Rich,
Pete

------------------------------

>
> Message: 3
> Date: Wed, 12 Jun 2013 13:22:39 -0400
> From: Richard Pieri
> To: discuss
> Subject: Re: [Discuss] Exim sender_verify issue?
>
> Peter Jalajas wrote:
> > a) was only checking for A records, not MX records; and/or
>
> You can't use MX records for sender verify. MX records don't necessarily
> have IP addresses associated with them. For example:
>
>   dig peorth.gweep.net any
>
> There is no IP address associated with this host name. A reverse DNS
> lookup on any host claiming to be peorth.gweep.net will fail. The
> authoritative host name associated with the IP address does not match.
>
> This seems like what you describe the friend doing: his MTA is
> configured to say that it is a google.com host. It isn't any such thing,
> and the reverse lookup on his IP address confirms it.
>
> Your provider's system is doing precisely what it should: it rejects
> mail from improperly configured, probably malicious sites.
>
> > b) was not checking multiple nameservers.
>
> I would need to see some mail logs and DNS traces before commenting on
> this.
>
> --
> Rich P.
>
>



More information about the Discuss mailing list