Nobody seems to be commenting on the semantics side of things. This is a
problem since it is probably the only area where the group can actually make
a mistake that will not correct itself.
The DNS record can potentially contain a lot of different types of
information. Of these the most important set is the specification of
authentication credentials and in particular the set of credentials to be
supported in the initial spec which is a set of IP addresses that are
authorized by the domain name holder to send mail from that domain.
This set MAY be complete or incomplete, there may also be additional
information to guide particular types of processing (821, 822, accreditation
etc) but lets leave that asside for a moment. Lets first focus on the means
necessary to describe the addresses:
Question 1: Is it a SET or a LIST?
I contend that it is a SET and that the order of the information is
irrelevant. This is different to SPF. Considering it as a set has advantages
when you come to the means of describing it. You do not need to preserve the
order in which the statements appear.
Question 2: What administrative Use cases should be considered?
I contend that the following use cases are important, to avoid
restating them I list the mechansisms I think cover them. "CLOSED" means
that all the authzd mail servers are present in the set, "OPEN" means that
there are authzd mail servers that are not specified. + means and, and |
means that they are alternatives, + has operator precedence.
[U-Simple] MX + CLOSED
All incomming and outgoing mail from the domain is processed by the
same set of mail servers.
[U-Roaming] MX + OPEN
All incomming and most outgoing mail from the domain is processed by
the same set of mail servers. Some users send without relaying through the
outgoing servers.
[U-Hosted] REDIRECT | PTR
The outgoing mail service is hosted.
[U-WebMail] IP-Range + INCLUDE
A farm of several thousand machines sends outgoing mail for a
community of millions of web mail users.
[U-BULK] PTR | INCLUDE-QUALIFIED
An enterprise hires a bulk mail sender to send mail for a particular
campaign. It might be desirable here to limit the scope of the delegation to
a specific email address 'marketting(_at_)example(_dot_)com' rather than
requiring
total delegation.
[U-ISP] PTR
An ISP tells its users to configure their mail clients to route mail
through smtp.example.com or mail.example.com. To configure the MARID set the
ISP simply writes a PTR record to the relevant DNS address.
[U-FORWARDER] ?
[U-MAILLIST] ?
Don't see why these would be any different from a standard mailer.
What are we missing here?
Question 3: What mechanisms are required to encode the set?
I contend that it is sufficient to consider 3 IP address encoding
mechanisms MX, PTR and IP-Range and in addition a REDIRECT or INCLUDE for
the entire MARID record. But I list some other choices.
Since MX can be encoded using PTR with better efficiency for lookup
and minimal additional admin I would recommend we only support PTR and
IP-Range. Because records can be large I think we also need INCLUDE. Since
INCLUDE can also support REDIRECT. I would want to hear Margret say it would
work to do INCLUDE-QUALIFIED.
MX: the input MTA is always the output
"mx" style config avoids inconsistency. But since mx translates
to a DNS name anyway, is this really useful?
i.e. say we have MX -> mx.example.com is "mx" really better
than "ptr mx.example.com" which saves a DNS lookup round trip
for the receiver and does not appear much more complex to admin?
PTR: output MTA is described by DNS A record
This seems to be essential to me. The bulk senders have
to have this type of capability if they are going to
support RFC 822. But it is also useful to avoid config
errors. I am required to send outgoing mail through
mail.comcast.net on one of my accounts. it is pretty
easy to see that comcast will keep that dns name aligned
with outgoing mail config with great accuracy.
IP-Range: IP address range specification
This is probably the route for a lot of large enterprises who
know their external IP address blocks pretty well. It also
allows for authentication of users of pooled addresses. this
clearly requires v4 and v6 variants.
In a large enterprise the mail admin may not be able to control
the IP address the mail server has assigned with confidence.
It is probably maintained in the firewall DMZ zone.
This type of specification also appears to me to be useful
as a compression technique for ridiculously big ISPs.
IP-Value: IP address value specification
Clearly this is a special case of IP-Range, but some may argue
that we do not need ranges.
REDIRECT: The entire MARID record for this domain is recorded at
a different location, redirect to that location.
INCLUDE: A part of the MARID record for this domain is recorded
at a different location, obtain the information from that
location and insert it into the record at this position.
INCLUDE-QUALIFIED: Same as above but only operates for a specific
email address within the domain.