It would be useful for Mail Transfer Agents (MTAs)
<strike>implementing
message acceptance restrictions </strike> to be able to confirm that
information provided by peer MTAs' is consistent with a description
of the configuration of the purported origin.
There's any number of possible uses for the information. Need
it be limited
to one kind of use? (so if Phillip can't bring himself to say
'policy' we
shouldn't say anything narrower). Consider an MTA that just labels the
message ... leaving accept/deny to another entity.
Brilliant.
And moreover a little later in the charter there is a line to say that
this is not the only use:
"While the primary current use case for this facility is to combat
a certain class of domain forgery in spam, the solution chosen
should be generally useful for MTA-MTA authentication."
I think that is enough context for a charter.
If we do write a spec that does MTAMARK type work then the uses are likely
to be quite broad. For example when our anti-phishing response incident unit
finds a site the first thing the response engineer wants to know is who
hosts the site and what type of site is it. It is very likely that we would
pull up information from MTAMARK to display on the response dashboard to
help her.
This is another reason that I am keen to avoid policy commitments on the
part of the sender. If you tell me that an IP address is a cable modem
pool or an unattended PC in a cyber cafe I will probably respond very
differently.
Phill