> On Jul 14, 2016, at 2:39 PM, Franck Martin <fmar...@linkedin.com> wrote: > > I kind of see the null MX as a way to say that this domain does not send > emails.
Eh... only indirectly, implicitly and only kinda. 0-mx-dot states that the domain does not receive email for any address. It doesn't say anything directly about whether mail is sent using email addresses in that domain. If you believe that you must be able to deliver an asynchronous bounce for any message you receive, and you receive mail with an 821.From that you know is undeliverable then it's reasonable to treat that mail with a lot of suspicion. But 0-mx-dot is not an explicit statement by the domain owner of "mail is not sent using this domain". That'd be an SPF -all, or something DMARCy. Cheers, Steve > So it is more a test on the receiving side than on the sending side. > > On Thu, Jul 14, 2016 at 2:04 PM, Steve Atkins <st...@blighty.com> wrote: > > > On Jul 14, 2016, at 1:38 PM, Brian Godiksen <br...@socketlabs.com> wrote: > > > > I noticed inconsistencies in how domains are publishing null MX records. > > In RFC7505 it states these records should be published with a preference > > number 0. I am seeing a variety of preferences specified though. > > > > Example: > > > > ;; QUESTION SECTION: > > ;hotmai.com. IN MX > > > > ;; ANSWER SECTION: > > hotmai.com. 2530 IN MX 10 . > > > > Is anyone ignoring the preference number in their implementation? > > More generally, is anyone special-casing this rather than just treating it as > an idiomatic way of creating an email address that immediately fails to > deliver? > > Cheers, > Steve > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
