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:[EMAIL PROTECTED]> Brandenburg InternetWorking <http://www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
