If we're going to start standardizing spam countermeasures I'd like to
see IESG or the Apps area adopt a strategy for dealing with the variety
of proposals I suspect we're going to see, as various groups seek to
gain legitimacy for their work. For instance:
1. Since I doubt we'll be able to decide exactly which set of
countermeasures should be widely implemented, my guess is that we'll
end up publishing several competing proposals at Experimental and/or
Proposed and re-evaluating them after a time in light of operational
experience and market acceptance. If we are going to do that we should
publicly say so up front, so that we have some semblance of uniformity
and we aren't as likely to be accused of favoritism.
I think this is the course we're on, like it or not.
2. Some spam countermeasures are "riskier" than others, in that they
use less-than-reliable criteria for classifying mail as spam, or they
adversely affect mail reliability for other reasons, or they change
SMTP or the mail format in inappropriate ways. If we are going to
publish risky proposals I'd strongly prefer that we publish them as
Experimental rather than Proposed. Proposed standards should "do no
harm".
Agreed. However, I don't think this proposal qualifies as particularly
risky.
However there still might be some value in publishing risky proposals
as Experimental -
First, to invite review of those proposals by experts within IETF and
where feasible, to encourage modification of those proposals to minimize
their potential for harm
Second, to encourage modification of those proposals so that conflicts
between them are minimized;
Third, to provide the opportunity to clearly label which proposals are
seen to be risky and for what reasons
This reason resonates the most with me. I've seen the notion of "it is
better not to publish stuff with issues" backfire far too often now.
Fourth, to encourage better collection of experience with
implementations of such proposals (since people are already widely
using risky countermeasures, we can't expect to stop them - but we might
as well try to learn from it)
Yep.
Layer 2: this proposal specifically
1. The basic idea seems good and "mostly harmless", but I think it needs
substantial revision before being adopted. With appropriate changes,
I'd recommend it for Proposed PROVIDED there's a pre-announced policy
on how we're going to deal with similar proposals. I don't think we
should be appearing to endorse this specific approach over other
approaches at this time.
It isn't clear to me what form such an announcment should take. I suppose
the IESG could include something about it in the approval notice.
2. [section 2] Nit: to me it seems confusing for solicitation-keywords
to be a single ehlo-param (in RFC 1869/2821 parlance) and for the
keywords to be comma-separated. I'd like to see us keep EHLO responses
fairly simple and uniform in format. Have we had comma-separated
keywords in other EHLO responses?
No, but we do have at least one ELHO parameter that accepts a
keyword list: AUTH. Spaces were used in this case, however, I cannot
say I forsee a major problem with using commas here. OTOH, I have no
problem with switching to spaces for consistency with AUTH.
I guess the idea is to keep one syntax for "solicitation-keywords"
that can be used in both EHLO response and MAIL FROM command. That
might be better than having two separate grammars.
Yes, that's the tradeoff, and its why I didn't recommend a change
to the EHLO syntax in my review. I can argue this one either way.
3. [section 2] Nit: it would be better if the entire grammar for
the EHLO response were in one place, rather than spread over
multiple sections.
A collected grammar at the end is better still, and I believe Carl
has stated that he plans to do this.
4. [section 2.1] Nit: the last paragraph seems out of place;
I think it should go in an acknowledgements section near the
end of the document.
Alterately, the convention we used in the MIME specification of having
HISTORICAL NOTES could be used instead.
5. [section 2.2] I understand the need to define some initial
solicitation classes but I'd like to see us avoid endorsing
these. The MAPS-UBE class in particular, while it makes an
interesting topic for discussion, doesn't strike me as something
that we should endorse by making it a built-in part of a standards-
track protocol. 2.2.1 does say "for illustrative purposes only"
but similar disclaimers in other standards have been disregarded.
Yes, this one made me nervous as well.
More generally, what I'd like to see is a separation between the
specification of the protocol engine (i.e. the grammar) and the
specification of solicitation classes. (I realize that we've
traditionally included some keywords in grammars for other protocol
specifications. I think we need to stop doing this, as it makes
the grammars more complex and less useful for both protocol
implementation and constructing protocol verifiers.)
Sounds reasonable to me.
So the protocol engine is what should be standardized, and we should
have some initial solicitation classes registered that are not part of
the standard (they could go in an appendix to the document labelled
"initial solicitation class definitions" that says "not part of the
standard").
Good.
It would be okay with me to use some of the initially defined classes
in examples.
Finally I think this is one of those cases where x- fields might not
be a good idea - at least, I'd like to encourage public review of
new solicitation classes.
I was wondering what you and others would say about this... I tend to
agree that this is a place where X- could be harmful.
The grammar should be rewritten to reflect these various changes. For
instance:
Solicitation-keywords = registered-word 0*("," registered-word)
registered-word = ALPHA 0*(wordchar)
; registered-word(s) are registered
; with the IANA
wordchar = ("-" / "_" / ":" / ALPHA / DIGIT)
Yes, this is cleaner.
6. [section 2.3] Is it possible that the recipient doesn't want to
disclose the reasons for rejecting the mail? Perhaps there should
be some generic indication that the message was rejected due to
policy rather than because the recipient address was not valid.
(550 is the right code but is probably overused.) Or maybe this
proposal should just require ENHANCEDSTATUSCODES as 5.7.1 is a
clear indication that this is a policy violation without saying
exactly what policy is violated.
Now that you bring it up, some mention of the enhanced status code
to use is probably in order here.
If nothing else this should make clear whether the policy indication
is in some machine-readable format (is it part of the protocol?
if so, what's the precise syntax?) or is meant to be human readable.
Is it conceivable that a recipient might be willing to accept some kinds
of solicitation but impose various limitations or quotas on that kind
of mail? In this case a 4xx error code and 4.7.1 status code might be
appropriate to indicate "go away, come back later".
How about stating that an implementation MAY impose limits such as
message size restrictions based on solicitation classes, and that when
such limits are exceed they SHOULD be reported using whatever status
code is appropriate for that limit?
7. [section 2.6] I have strong objections to various parts of this
section:
- Most of this proposal is about giving the sender a way to assert
that a message is a solicitation, and that seems to me to be
"mostly harmless". Giving intermediaries a way to make similar
assertions is "risky" and I don't think such a practice should be
standardized.
For example: a sender can assert (rightly or wrongly) that an
advertisement is solicited by a recipient and be in a position to know
whether that assertion is true; an intermediary cannot be expected to
know whether such an assertion is true.
- Letting intermediaries' assertions get confused with the sender's
assertion (as provided for in section 2.x) is even worse, and I'd regard
that as something that should not even be published as Experimental.
- Even accepting that it's useful for intermediaries to make assertions
about the solicitation classes of a message, it's not at all clear
that the classes that can be asserted by an intermediary are similar
to those that can be asserted by a sender. An intermediary can
make assertions about content (e.g. "this message contains a GIF image")
but is not in a good position to make assertions about intent.
- Even accepting that it's useful for intermediaries to make assertions
about the solicitation classes of a message, I don't think the Received
field is a good place to do that, and I don't like the idea of storing
protocol elements in comments or of having MTAs read and trust the
contents of comments. MTAs should as much as possible treat message
content as opaque.
I strongly recommend that this document NOT provide a way for
intermediaries to make assertions about solicitation classes,
as that seems orthogonal to the main purpose of this document,
and it seems to make it much riskier.
The risk has to be weighed against the desireability of being able to capture
such assessments and being able to associate then with a specific agent. This
is another one I can argue either way.
Even accepting that it is useful for intermediaries to make
assertions about solicitation classes, the protocol for doing this
should be defined in a separate document, and those assertions should be
kept cleanly separated from assertions made by the message originator,
and there should probably be different classes for those indications.
8. [section 2.7] The wording is muddy. It appears to apply only
to SYSTEM-WIDE, and that doesn't seem right.
IMHO, anytime a server asserts NO-SOLICITING in EHLO, this means:
- if NO-SOLICITING SYSTEM-WIDE is asserted and a set of prohibited
solicitation classes is included, client SHOULD NOT attempt to relay
mail for which the SOLICIT= MAIL FROM parameter includes a class that
is prohibited in the EHLO response.
(however if the client does so it's still the server's responsibility
to reject it)
- regardless of whether a set of solicitation classes is included
in the EHLO response, client MUST convey SOLICIT= faithfully (i.e.
as received from the previous hop) in MAIL FROM for each message
relayed to a server that supports NO-SOLICITING.
Seems reasonable to me.
9. Actually I suggest getting rid of the SYSTEM-WIDE and PER-RECIPIENT
keywords. Here's why:
- it's useful to allow a combination of SYSTEM-WIDE and PER-RECIPIENT
policies, rather than to force one or the other. The SYSTEM-WIDE
policies would apply to all recipients supported by that server,
but individual recipients could have more restrictive policies.
Interesting notion. I think I like it. So you'd have a list of "globally
unacceptable" keywords in the EHLO announcment but allow per-recipient
rejection on the basis of the SOLICIT= MAIL FROM parameter? Yes, this
definitely is an improvement.
- it's useful for an MTA to have the ability to relay SOLICIT=
indications even if it doesn't actually impose system-wide or
per-recipient restrictions. Yes, it could claim PER-RECIPIENT
and then never impose any restrictions, but that seems misleading.
Of course. I missed this issue entirely; sorry.
I'd also suggest changing the name of the EHLO keyword because
supporting relaying of SOLICIT= doesn't imply that the MTA has any
restrictions on soliciting. So I suggest:
- rename the EHLO keyword something like "RESTRICT"
- allow the EHLO keyword to have system-wide options. e.g.
RESTRICT means that the SOLICIT= keyword is supported but that
no system-wide restrictions are advertised, and
RESTRICT=class1,class2,... means that the SOLICIT= keyword is
supported and that class1,class2,... are prohibited on a
system-wide basis.
Careful here - there is no equals in the syntax here. (I'm sensitive to this
issue because Microsoft botched its handling of AUTH and now servers may have
to advertise AUTH=FOO in addition to AUTH FOO.)
10. Somewhere some text like the following seems appropriate:
Note that the system-wide option, while useful, is of marginal
value. Many MTAs want to be able to accept mail for multiple domains
that may have different policies, and any large user community will
probably need to have different policies. Typically there are some
people in an enterprise who _need_ to be able to receive advertisements-
e.g. people who do procurement and who naturally need to know what goods
are available at what prices from which sources.
Honestly, I don't think it is all that marginal. There are lots of fairly
specialized SMTP servers for which the system-wide option makes considerable
sense.
11. [section 2.8] The ability to relay SOLICIT= SHOULD be enabled by
default. However the default configuration SHOULD NOT impose any
system-wide or per-recipient policy.
Agreed.
An MTA that advertises the EHLO keyword MUST relay SOLICIT= faithfully
to any next-hop MTA that advertises the extension in EHLO.
Agreed.
An MTA that advertises the EHLO keyword MAY implement the ability to
advertise a system-wide policy in EHLO. If such a policy is advertised
it MUST be enforced by rejecting messages for which MAIL FROM asserts
a solicitation class that conflicts with that policy. (It MAY also
be enforced by other mechanisms, e.g. looking at the Solicitation:
field and rejecting messages for which that field conflicts.)
For completeness, sure.
An MTA MAY also implement a system-wide policy without advertising
all of that policy in EHLO.
Why not?
An MTA that advertises the EHLO keyword MAY implement per-recipient
policies for zero, some, or all of its recipients.
Sure.
12. [section 3] I think this belongs in an appendix, as it seems
to be non-normative.
Seems reasonable to me.
13. It is fairly obvious that sites and recipients will want policies
based on reliable characteristics of the message other than a
solicitation class advertised by the sender. e.g. I want to be able to
reject application/ms-word documents. And then we also have things like
the content-negotiation stuff that the fax people want. Given this,
what is the potential for conflicts between these various policy
mechanisms? And should we try to sort them out now or wait until later
when we have more experience with them?
I think waiting on this would be a mistake for a variety of (probably fairly
obvious reasons).
Ned