Cheers Jeroen, > If you are anti-spam, don't bother checking this (dom.com 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: > > https://tools.ietf.org/html/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 rfc. > 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;-)) Ciao, Markus _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
