Hi.
First, my apologies for taking so long getting this note out.
I've got a large number of end-of-year commitments and deadlines
(unrelated to the IETF and mostly unrelated to the Internet)
that have to take priority over volunteer activities like this
one. And each time I've come back to this since Tuesday morning
I've wanted to review all subsequent postings on the IETF list
and the parallel discussions on the ietf-smtp one to see if they
would change the response (some have). For those who don't
like my long notes, please average this one out over nearly a
week and the multiple shorter notes I could, in principle, have
written during that tine. In any event and rather than trying to
respond to postings and points one at a time...
I think several recent postings are missing the point I (and a
few others) have been trying to make even if they are
interesting and/or useful, so let's back up a little bit. I've
changed the subject line a bit in the hope that we can get back
to the original discussion and let the other subthreads go where
they will.
If some random, or not-to-random, party decides it doesn't want
mail traffic from anyone who uses an IP address literal in the
EHLO and/or MAIL commands, or doesn't want to accept mail that
uses, e.g., an RU or рф TLD or that has a PTR record or
originating connection address that appears to be from that
country [1], they have the perfect right to reject such traffic.
It makes little difference whether they think the spam:wanted
mail ratio is too high for mail that appears to be originating
there or because of some unrelated (and either rational or
irrational) dislike of the country, etc. One can substitute
any domain, address type, address location, etc., one wants in
that example and the principle remains the same. As an even
more extreme example, if someone is stuck in the 1990s or
suffering from an extreme case of ICANN aversion decides to
reject any mail transaction with a TLD name more than three
characters long or any DNS label that is an IDN, that is not an
IETF problem. If we were writing a best practices document we
might recommend against several of those things, but that is a
different matter entirely -- the receiving MTA operator still
has the perfect right to decide what they will accept.
Russ Allbery's comments about different priorities among
different mail servers operators are, it seems to me, exactly on
point in this regard. If we were writing a best practices
document and wanted to be honest about it and reflect
present-day realities, we'd probably need to say "if you are
trying to optimize for this, then you should do... and if you
are instead trying to optimize for that, then ...". I'm not
sure "reliable delivery of anything that might be legitimate"
and "an absolute minimum of spam gets through" are the only two
categories, but they are a start. Unlike Keith (if I make the
right inference from his comments), I think we have some
responsibility toward people who are making both sets of
choices, including discussing tradeoffs, not just taking
responsibility for the "maximize reliable delivery" folks and
letting the others dig their own versions of whatever holes they
want to get into.
However, the thing that convinced me there was an issue worth
raising on this list is that these are IETF mail servers. I
think that factors into the choices of how to optimize and what
to optimize for. Either they should adhere to the standards
(which, in the email case, are definitely optimized for reliable
delivery because that seemed to be the only reasonable practice
when they were written) or we --the IETF community or at least
the subset who are concerned with mail standards-- should know
about it and consider whether the standards need upgrading or
supplementation.
Deviations on "our" servers from what the standards require (or
even recommend) should be taken seriously for several reasons:
(1) We claim to be -- and need and want to be -- open to anyone
who is interested in participating. Making would-be
participants jump through hoops, switch mail providers, shut
down mail systems that are personally and locally operated in
favor of virtual arrangements in easier-to-work-with
environments, or forcing switching of mail or Internet service
providers, is, at least IMO, inconsistent with that goal.
Noting the protections built into or procedures for taking
posting rights away from individuals, it seems unreasonable to
deny such rights and protections to those who systems conform to
our standards but are somehow a bit out of some definition of
the mainstream. It also suggests that we should go to extra
efforts to be sure that any actions that are taken in the IETF's
name that could reject legitimate mail should be examined to be
sure there are not more finely-focused alternatives that would
have a lower false rejection rate. For the particular case of
email spam (and has others have pointed out in comments that
also seem to have gotten lost), that argues for concentrating
more on message-specific properties such as known-problematic
origin addresses, the arguments to the MAIL command, and/or even
specific subject lines or content or pattern indications
(although others have pointed out the disadvantages of doing
in-depth message body inspection and I agree) than on blunt
instruments like rejecting all IP address literals (or
everything from a given domain). If we are going to create
barriers to participation in the IETF for classes of people
based on their choices of mail clients, submission servers, or
mail providers --people who, as far as we know, would be
constructive and helpful participants who would bring us more
diversity and broader perspectives-- I think that deserves at
least as much consideration by the IETF (or at least the IESG)
as a decision to exclude a specific individual for a pattern of
bad behavior.
None of that is micromanaging the Secretariat or anyone else:
they are principles and guidelines about who gets to participate
in the IETF, who we are willing to exclude, and why.
(2) There are many reasons why what the IETF mail servers do
should align with what the IETF is telling others to do.
Getting into "do what I say, not what I do" situations is almost
never productive. Standards bodies who don't follow their own
standards develop sometimes-serious credibility problems and may
call the relevance of their standards. even in completely
different areas, into doubt. As things evolve, that may mean
changing the standards to align with the practices, it may mean
aligning the practices more closely with the standards, or it
may mean just documenting the differences and the reasons for
them. It does mean that either the Secretariat or IETF LLC need
to be thoroughly familiar with the relevant standards or that
they need to have an advisory process that can provide that
calibration because if we care about encouraging the use of our
standards, at least IMO, the one thing we need to avoid is
making uninformed or accidental decisions. "Ask the IESG if you
have questions" is perfectly reasonable as long as they have the
expertise to know when to ask and, unless the answers are
really obvious, the IESG consults community experts in an open
and transparent way. Again, that isn't micromanaging the
Secretariat -- it is making general expectations clear and being
sure the Secretariat has the resources to meet them.
In that context, it is likely that the "IESG Statement on Spam
Control on IETF Mailing Lists" policies to which Alissa pointed
[2] is actually in need of review for at least two reasons:
(2.i) The first is a nit (or set of them) but may point to what
got us into what I see as a problematic situation. While it
could probably be corrected by tuning the error message, bullet
4, "IETF mailing lists MUST provide a mechanism for legitimate
technical participants to determine if an attempt to post was
dropped as apparent spam." is not satisfied by an error message
that claims a RFC 2821 (or 5321 if it were updated) restriction
since there are no restrictions in either document about spam
and they allow (and at least strongly encourage) allowing IP
literals. If the message said "your attempt to post was
rejected because you used an IP address literal in EHLO and we
therefore think you are spammer", that would comply with this
MUST requirement. It would be more in the spirit of the sixth
(last) bullet if the message went on to say "if you think this
rejection is in error, contact..." with appropriate information
there.
(2.ii) As discussed in (1) above and in the light of many IETF
discussions and statements made in the last decade it seems to
me that an IESG anti-spam policy statement should be clear that
particular decisions to avoid spam should carefully avoid
discriminating against current or potential IETF participants
based on variations in connectivity, locations, and the like
unless there are no plausible alternatives.
(2.iii) In addition, as I think others have pointed out, the
statement points to a previous one for justification and
implementation advice, but the link given just points back to
the 14 April 2008 document. And, in light of administrative and
other structural changes made since 2008, the Managing Director
of the IETF Secretariat, the IETF LLC Executive Director, and
probably the IAB and IRTF Chairs and the Independent Submissions
Editor, should probably be added to the "MUST be able to post"
list and the term "The Internet draft editor" clarified. Under
normal circumstances, I would be among the first to argue that
the IESG has better things to do than to track this type of
statement regularly and tune it, but, since the statement has
come up in this discussion and been cited as the current policy,
those fixes should probably have some priority.
(3) Several people have suggested that, if only one problem has
been reported in a decade, there is really no problem worth
worrying about. This calls for a short statistical lecture
about sampling from censored data and/or a population different
from the one that inferences are being made about that I've sent
to a few people offlist, but I'll skip it here. The short,
practical, version is that, if someone wants to participate in
the IETF but their attempts to post to our mailing lists are
frustrated by error conditions that are not properly reported,
with error messages that they may not even see, and with no
obvious (to them) way to get help with the problem, most or all
such people just go away. They do not become part of our record
about who had problems and we have no plausible way to determine
whether there are no such people or hundreds. So "there have
been few reported issues and we shouldn't spend time on this"
just does not hold water. If we could know how many legitimate
messages or participants had been rejected by filtering
connection attempts with IP address literals in the EHLO field,
we could have a useful discussion about whether the number (and
types) of people who are being inconvenienced or deterred from
participation are ok to lose. But we don't know... and, if
Hector had not been a very long-term participant who knew which
list to ask on and had alternate posting mechanisms readily
available, it is reasonable to assume we would not have heard
about his case either.
best regards and best wishes for whatever people are celebrating
and for a 2020 with fewer issues like this one.
john
----------
[1] Examples chosen because I see a lot of spam from that
country, but other examples would work equally well.
[2]
https://www.ietf.org/about/groups/iesg/statements/spam-control-2008-04-14/
