Carl Malamud wrote:
Hi Yakov and Philip -
Let me take your comments in reverse order.
Thanks for the quick response!
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.
I have no problems with your specific draft, rather I am afraid of it
being overloaded and used for things other than solicitions and more as
a generic policy mechanism. It would be helpful if the IANA registry
guidelines are restricted to only "solicition" stuff, and nothing else.
There are problems with policy expression mechanisms mainly from the
design point, since this particular mechanism was intended for a
specific purpose, overloading as a generic mechanism might not work so
well. Therefore, it might be better to have a separate generic policy
mechanism.
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.
One possibility I was wondering about - what if Saudia Arabia wants to
register a keyword for "ISLAMIC-conformant email" in order to censor? It
would be highly recommended that the IANA registry operates under
specific guidelines and restricts these keywords to "NO SOLICIT" stuff
only, and not anything else. In any case, that would probably be up to
the IESG.
As to using a keyword not in the registry, then suing [iana, ietf,
recipient, sender]? I'm not sure I get that one.
The basic premise of this is to provide ability to pursue the spammers
legally by giving them prior notice. Being that SMTP uses English and
somewhat readable keywords, it is feasible that someone will use these
to give notice with "semi" English keywords they made themselves, and
then try to sue incoming emailers for not keeping them. And these "semi
English" words maybe something else other than spam, although I am not
sure if such lawsuit will ever be successful.
In any case, these are not technical issues but rather is social ones.
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.
Nevertheless, this mechanism is intended for legal use as the draft
describes:
" The service extension allows a mail recipient to notify the sender
that certain forms of electronic mail are not desired and thus gives
policy makers a mechanism for requiring senders of such electronic
mail to identify their missives any penalties for failure to do so.
"
The problem that Philip is pointing out is not relevant to the actual
draft, rather to the idea behind it - the fact the multiple
jurisdictions have multiple laws, and for emailers to comply with them
would be complicated. But as John pointed out, there are many laws
anyway today, and governments are passing even more. Having a single
mechanism might or might not make things simpler.
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.)
I would also recommend that whomever wants to submit comments on these,
should do so to the IESG directly. Keep in mind, that if you mention
that you are an ASRG member, nevertheless do not make it sound that you
are speaking for the whole group.
Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I want to know G-d's thoughts... the rest are details" (Albert Einstein)
-------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg