Hi Yakov and Philip -
Let me take your comments in reverse order.
In any case, it would be useful to hear what the author has to say to these.
There is also another issue of exchanging policy information between
sending and receiving MTAs, which is related to what SPF is trying to do
as well with extensibility.
I've tried hard to keep this draft very focused on a simple mechanism
that allows a sender or an mta to assert keywords, a receiver to
assert keywords, and a registry to keep track of keywords.
I agree it could, in a sense conflict with potential future solutions.
But, the hope is that the extension meets the "probably won't hurt,
might help" criteria of protocol design. So, if SPF does something
in this area, perhaps they could use this mechanism as a partial
transport or perhaps just ignore it. I don't see how it could hurt.
The current draft sets out that IESG or IANA should appoint a designated
expert to do these. This may provide some oversight. However, another
problem is that people might use it without going through the registry
and use that as a basis for a lawsuit anyway.
Well, if I were the designated expert (and, believe me, I'd rather not),
I'd set up the registry using some neutral algorithm. For example,
if you have a verifiable email address, a verifiable reference
URI, then keywords are allocated on a first-come, first-serve basis.
As to using a keyword not in the registry, then suing [iana, ietf,
recipient, sender]? I'm not sure I get that one.
Philip Miller wrote:
- 'A No Soliciting SMTP Service Extension '
<draft-malamud-no-soliciting-04.txt> as a Proposed Standard
Promulgation of this document as an RFC would encode exactly what we
tried to avoid with our consent framework: content-specific solutions
that are open to definition wars, redefinition, and even worse,
cross-border legal wrangling. It requires that senders, to be compliant
with every possible national law, check their mail against each and
every registered keyword.
No, no, no. :) The draft provides a mechanism for the transport
of solicitation class keywords. It does not say when a message is
accepted or rejected, or when to send it, or anything else having
to do with consent. If you want to assert a keyword (or are required
to by a license agreement or other governing document), this is,
imho, a much better mechanism than inserting them into subject
headers, non-standard headers, or other mechanisms.
I believe that the acceptance of this proposal would be harmful to the
operation of the global mail transport system. However, I want to hear
some other opinions before submitting my comments to the IETF.
Also, should we, as a group, submit a collective opinion, which may
carry more weight than just our individual statements?
I would recommend against that course of action. ;) Seriously,
why would the asrg take a group position on this? If you don't
like the draft, send the iesg a note and explain why.
(I'd highly recommend a look at the ietf-smtp list, where it appears
to me there is at least a glimmer of possible consensus.)
Regards,
Carl
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg