1. Express the set of "authorized" mailers for a domain. (REQUIRED)
1a. Minimal approach would be a list of IPs or hostnames,
similar to MX
1b. A flexible language like "a mx ptr" can save me a
step when adding
MTAs later. The actual language is not important, but "flexible
mechanisms" is an important feature to me
If you are going to use the term 'authorized' at least make it
clear that it is a relative term. The term 'authorized by the domain
name holder' would seem to be what you are trying to state.
I still think that it is clearer to state that the DNS record
describes the credentials that will be presented by legit mail
servers since the real semantics of the DNS record is
"You will know that a server is an authorized mail server
for example.com by the fact that it presents the IP address
X, Y or Z". This leads to much clearer descriptions later on.
Secondly it is a SET of IP addresses, not a list, the ordering
does not appear to be useful in this case. This will be important
when we consider ways of expressing that set.
I don't think the justification for the flexible language is to
save time, avoiding configuration inconsistency would be my motive.
I see some important admin issues here:
1) Simple config, 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?
2) PTR style config, 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.
3) 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.
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.
2. Express other mailers as unknown, or known bad. (Strongly
recommended)
2a. Analog to spf ( - ? ~ )
2b. Ability to express a "default" or "fallback" included here
The way I see it the set of mail servers that are issued credentials
is either fully specified or only partially specified.
I think we need three values:
Complete: The description of the legit mail servers includes every
legit server.
Incomplete: The description of the legit mail servers is known to
be incomplete
Test: It is not known whether the description of legit mailservers
is complete or incomplete.
The distinction is seen when we consider what might happen when a
suspicious mail comes from anybank.com:
Complete:
If the mail message is consistent then it is not phishing
If the mail message is not consistent then it is phishing
Incomplete
If the mail message is consistent then it is not phishing
If the mail message is not consistent draw no conclusion
Test
If the mail message is consistent then it is not phishing
If the mail message is not consistent tell anybank.com
I think that we will eventually want to add some form of reporting
structure to be used when an impersonation spam is seen.
3. Ability to include other domains (and get their LMAP info)
by reference
3a. Analog to include: mechanism
I think this is definitely needed for certain types of user, but I
would rather go by a list of use cases than look at mechanism
piecemeal.
4. Extensible enough to include some data we haven't thought of yet
4a. Analagous to spf modifiers "foo=bar" which can be
ignored by older
clients
4b. "Extensibility" must be treated with caution... for
now we can
postpone discussion of syntax and just say "Extensibility" is
a required feature.
I think that we need the equivalent of the PKI criticality flag.
But we also need to understand whe 'break everything' is useful.
If we say that we are issuing credentials to mail servers then
what to do when we see a credential we do not understand is obvious,
we simply treat the record as if it was specified as incomplete.
We do not need to abort processing as SPF insists.
It also seems useful to be able to note extensions which will not
lead to the record being considered incomplete if not understood.
I can imagine that anybank might want to say things like:
Every email we send comes from this list of IP addresses
Every mail server we operate offers the SMTP SMIME extension
Every mail server we operate offers STARTTLS and the root cert
is XXXX
While some other user might want to say
My home mail server is X, I sign all my mail with S/MIME when on
the road.
So the S/MIME authentication credential leads to incomplete being the
default in the second case but is an above and beyond offering in
the first. This makes sense from the POV of the attack profile.
I do not expect penis potion peddlers tohijack BGP routes, I do
expect the ex-USSR crime gangs operating the main phishing scams to
do so.
There are more "features" I am skipping here that have to do
with semantics
but I think these are the "core" that hopefully everyone can
agree on. Anyone want to add to the list?
More useful perhaps might be to subtract :-)