Phil,
Wednesday, February 26, 2003, 9:14:01 PM, you wrote:
PK> I would like to propose that the IAB consider drafting and adopting a
PK> position statement on the highly deleterious effect that certain
PK> anti-spam mechanisms have on legitimate, efficient uses of the Internet.
The timing of your note is interesting. Last summer I tried to debate
the port 25 issues with Nanog folks. I've now given up that debate
because to many of them think it is useful. Telling that, for
example, spammers have simply started using webmail as a channel does
not seem to matter. (Let's see them start to block port 80...)
So at the recent Nanog meeting I tried to suggest a collaborative
effort between the IETF and ops folks to formulate a BCP that
specifies a single, preferred set of choices for doing remote email
access.
Here is a copy of the note I posted on 30 January, to Nanog:
Folks,
The Ops community and the IETF Email community appear to have different
views about appropriate methods for email posting. The difference
frequently means that an effort to post a new message from a network
with a firewall, to a remote SMTP, is blocked by the outbound firewall.
Blocking outbound SMTP (port 25) is supported by the Ops community as a
spam-suppression mechanism. Ops support for this blockage appears to be
deeply and broadly held.
This note is *not* an effort to debate the Ops concern or the preference
for blocking outbound port 25. Rather, I would like to pursue a
discussion that simply resolves the disparity between the two
communities.
The goal is to obtain a coherent recommendation that is acceptable to
the Ops and the Email communities.
It would permit normal users to easily use their normal software and
achieve normal access to normal services. Whatever the current choices
are, they are inconsistently available and they frequently require
technically knowledgeable users and/or special cooperation by the user's
remote ISP.
My guess is that a brief IETF BCP document would suffice for describing
the recommended profile. For completeness, I suggest that the BCP cover
"Remote email access" for posting and retrieval, and that it recommend
the details that will permit private, authenticated access for all
standardized email services.
Some current choices:
Email standards provide for posting of email to the usual port 25 or to
port 773 for the newer "submit" service. (Submit is a clone of SMTP that
operates on a different port and is permitted to evolve independently of
SMTP, in order to tailor posting by originators, differently from
server-to-server email relaying.) There is also a de facto standard for
doing SMTP over SSL on port 465, although this collides with the IANA
assignment of that port to another service.
Standardized SMTP authentication uses the SMTP Auth command or the SASL
service within SMTP. It can also use the de fact "POP hack". All 3 of
these mechanisms are inline -- as part of the posting protocol -- so
that they work over whatever port is being used for posting.
Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with
SASL. SASL can be used on any SMTP or Submit port. SSL can only be
used on port 25 if the SMTP service is not available to other SMTP
servers for relaying (or, really, for last-hop SMTP delivery).
Some choices are easier for users. Some are easier for service
providers. Some are supported more broadly in current software.
We need to narrow down the recommended choices, preferably to one per
service.
Thoughts?
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>