Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Author Topic: Null MX support?  (Read 1783 times)

mbence

  • Newbie
  • *
  • Posts: 2
Null MX support?
« on: December 01, 2015, 07:27:46 AM »

Hello,

I was wondering how to tell the world my domain does not accept mail at all. It looks like there is an official way to do it: Null MX / RFC 7505
Simply put:
@   IN   MX   0   .
It is a proposed standard already: https://datatracker.ietf.org/doc/rfc7505/

But when I try to set it up on the DNS.HE.NET web interface I get the following error message:
CNAME/MX/NS must point to a valid hostname. ()

I would love to have such a DNS record. Is there an official way to request such a feature?
(I plan to use it on my future domains so I would rather not ask support to add it every single time.)

Cheers,
Bence
Logged

snarked

  • Hero Member
  • *****
  • Posts: 746
Re: Null MX support?
« Reply #1 on: December 01, 2015, 01:02:38 PM »

I agree that the RFC you cited is the official way of marking that a HOST does not accept mail.  However, my opinion of the RFCs in general is that a DOMAIN itself may not be marked as such.  This is because there are certain mailboxes that every domain should/must have:  "abuse" and "admin" among them.  The SOA record is supposed to have a mailbox of the "hostmaster" (DNS maintainer), which can be outside the zone in which it appears.  "Postmaster" is only required when SMTP service is present.

Although this RFC does say that "domains" may indicate that they have no inbound SMTP server, that is in contradiction with the RFCs that indicate required mailboxes - and as this is a later RFC, it is required to resolve any conflict with prior RFCs (whether by stating it supersedes, or otherwise), but RFC 7505 fails to do that.

Don't forget that some smart MTAs might also try SRV records.  Therefore, a "_smtp._tcp IN SRV 0 0 0 ." record should probably also be specified.

If your attempt to enter a "MX 0 ." entry fails for hostname labels other than the domain itself, a bug is clearly present.  However, if this occurs for ONLY the domain itself (the "@" pseudolabel), it may be a POLICY ENFORCEMENT issue.
« Last Edit: December 01, 2015, 01:04:14 PM by snarked »
Logged