I think people are looking at the 'authority' issue from the wrong end.
Who has the 'right' to tell me how I can use an IP address? If you look
at the authorization question from the producer end of the equation
you will end up running right into a whole pile of mess.
Mere control of the reverse DNS for an IP address is not normally considered
to entail the 'right' to dictate the uses to which the address can be put.
continue on that line and you will find that you start redefining the
business model of the entire Internet. You can try to do that but if
you do you will not be finished in time to have any impact on the solution.
This is not a producer problem, it is a receiver problem. That is where
any control decision will be made. All that the sender is doing here is
providing some additional information that helps the receiver determine
that a message is legitimate.
If you word the spec the way it is going at the moment you will find
you have authorized things that you will really, really hate. For example
if I am a backbone carrier and I see an attempt to connect to port
25 outbound from an address that is not 'permitted' to send email
according to the spec I would be within my 'rights' to simply suppress
this packet.
| 1) The "is this IP address authorized to be an MTA?" question.
| (e.g., MTA-Mark, SS, DUL lists, etc.)
|
| 2) The "is this IP address authorized to use a given
domain name in
| the MAIL FROM (and HELO) address?" (e.g. RMX, SPF, DMP, etc.)
|
| 3) The "is this From: header from who it claims to be
from?" (GPG,
| S/MIME, DomainKeys, Caller-ID, etc.)
1) What type of IP address is this?
2) Does the use of the source MTA IP address comply with the sender
policy of the domain specified in the SMTP transport?
3) Does the use of the source MTA IP address comply with the sender
policy of the domain specified in the message body?
4) As a receiver will I accept the message?
We can even do away with the 'sender policy' confusion altogether
if we instead think of the information in the forward DNS as a
description of the mail configuration of the outgoing mail
servers.
Another advantage of the 'its just a description' point of view is
that we separate concerns. The sender is not doing authorization,
they are simply providing information to the recipient.
The recipient uses that information together with a model of how
email passes through the Internet to decide whether to accept
the message. One of the strong implications of the work in this
group is that the model of email transport in the internet is going
to change. I do not expect forwarding relationships to be maintained
in the same way as at present in a few years time. I think we will
move to a proof of consent mechanism (spec on its way soon).
If you follow the authorization model of thinking you end up with
a procedural description of how to interpret the data. That will
inevitably be out of date.
I think that the dictatorial tone of the specs is the legacy of the
blacklists. The problem there was that people started to order
people what to do and that is how the problem tends to be thought of.
We are helping people to help themselves here, not ordering them
about.