Some comments on the draft:
1) Section 5.
The scope here is outgoing email policy, identified by <ep><out>. Since we
have a 500 byte limit we are working inside and since outgoing and incomming
policies will always be used in separate operation I suggest that we
recognize this at the selector prefix level:
_out._ep. - For outgoing email policy
_in._ep - For incomming policy
I think that incomming policy will be very useful when domains are
communicating information like 'I process MARID records' or 'I accept S/MIME
& PGP signed email'.
Arguably such information could be exchanged inband in SMTP, but this is not
guaranteed to be possible.
Section 5.2
Are these macro expansions really necessary? Would it be possible to
eliminate them entirely or if some form of indirection is needed could we
simply define an element for that purpose.
I am unconvinced by the claims that MARID could be used for DDoS purposes,
but there are certainly lots of moving parts here.
Regardless, I am unable to parse the explanation of the macro functions:
l = local-part passed to the client authorization function.
s = Same as "%{l}(_at_)%{o}".
o = original domain passed to the client authorization function.
d = current domain passed to the client authorization function.
i = SMTP client IP (nibble format when an IPv6 address).
p = SMTP client domain name
v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6
r = domain name of the SMTP server.
local part OF WHAT?
If s is the same as "%{l}(_at_)%{o}" then why duplicate it?
I find it very hard to work out precisely what the terms original and
current mean in this context.
I really cannot see a justification for all this mechanism unless the idea
here is that the spec is going to somehow conform to legacy data sources
such as blacklists. That does not make a lot of sense to me since a
blacklist is accreditation data which by definition comes from a third party
and cannot therefore be interpreted without reference to the reputation of
the acreditation provider. If the receiver is tracking said reputation it
makes best sense for the receiver to also track the correct way to extract
the data from the service.
I would like to see some use cases to motivate this whole section. My strong
beleif is that it is possible to address this issue using elements such as
<username-include> and <ip-include> for include:%{l}.domain and
include:%{i}.domain and meet all the interesting use cases.
This approach would allow the spec to be further constrained so that a
factored record of this type cannot itself reference a factored record. This
ensures that the type of DoS attack hypothesized is completely eliminated.
There are at most two branches in the tree and only one branch is to be
followed.
Removing the macro expansions limits flexibility on the part of
administrators in the way that they format their data. This is usually a
good thing. Give two ways to express the same data that offer no advantage
and you create two code paths that have to be maintained, more importantly
you have two un-fun legacy protocol issues down the road.
The restricted examples given are still sufficient to allow support of use
cases such as delegating particular usernames to a specific email provider.
They can use a <username-include> to break up the record and
service(_at_)anybank(_dot_)com can point to a record at constant contact.
Equally if a
person wants to set up an outgoing mail server on a mobile machine they can
do that using an <ip-include> and dynamic DNS. Of course this still leaves a
problem if you are behind a NAT box, but the external NAT box address is
discoverable.
Phill