Cheers Jeroen,

> If you are anti-spam, don't bother checking this ( A); anybody
> who wants to receive mail will have an MX, if not, let them join the
> 2000s...

There are actually quite a few (definitely more than white noise) senders that 
don't have MX, and only use A records.
Many of these are from what I call "isp-in-a-box" resellers, who a) don't know 
how to properly setup their servers, and
b) since web-server-address and mail-server-address are the same, things "just 
work" if they only point their domain
name to the IP address of their virtual server. While I don't think that's a 
good setup, I'm not at the liberty of
denying our customers to receive mails from such senders :)

> Also, instead of bothering with the MX Lookup, verify and enforce SPF,
> DKIM and DMARC instead, they are meant for checking against the envelope

Oh, if a sender deliberately wants to break his mail delivery and defines such 
records, you can be sure we'll test for
them, and classify the mail as SPAM if they fail. We don't encourage their use, 
but you bet we'll enforce them if
they're set.

> From, MXs are not. Non-existence of a MX on a domain does not mean it
> does not get used for sending mail; thus you might have a small false
> positive rate there... (which you might chose to accept, you are the
> receiving end, hope you have an informative rejecting message ;) )
> Spammers will make sure that MX, SPF, DKIM and DMARC are all configured
> btw; they only really 'resolve' spoofing issues.

Yes, I consider SPF and friends evil, as I pointed out above, but will 
definitely enforce them when provided. My stance
on the MAIL FROM address is: if we accept a mail for delivery/relay, we also 
accept the responsibility to deliver back
DSN mails to the sender, if there is a problem with the finaly delivery of the 
mail later on. For that, we need a
valid, usable sender address. If there isn't one, we won't accept the mail. It 
is also a very effective tool to weed
out many spammers without resorting to content analysis (and is thus much more 
efficient, as well). MX to localhost?
bye bye :)

> I assume you also allow '<>' for DSNs?

I do, but I severely restrict what we allow in these mails, their size, only a 
single recipient, etc.

> If you do the above, you might want to check for "MX .", this indicates
> a domain that will never send mail as per RFC7505:

I don't have to check for this explicitly, because it will fail the A lookup 
check, so it will be considered an invalid
domain for an email address. But thanks for the pointer, didn't know about this 

> But again: MX is for _receiving_, not _sending_ (From) thus checking it
> is a bit wrong, but at your prerogative.

I explained my reasoning above, why we do verify the sender like this.

> Last note: do _not_ use 'host' for debugging DNS related issues, always
> use the very useful 'dig' tool, or if you want use 'drill' instead.
> ('host' hides various error situations and does not properly show what
> you are actually querying...)

I actually do use dig normally, I used "host" here because the output is much 
more terse and thus better suited to
explain a problem and keep the description smallish (my mail was too long 
already for some people;-))


swinog mailing list

Antwort per Email an