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 <mailto:dhc2@dcrocker.net> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850
From: "Dave Crocker"
The goal is to obtain a coherent recommendation that is acceptable to the Ops and the Email communities.
Email communities? You can't even get people to do proper reverse or secure open relays. A large section of the 'net isn't RFC compliant. Most servers are privately hacked so that no two are alike. And if an ISP is large enough and known for distributing information you don't want in your network, you're forced to accept it because your customers demand access to some of their customers. Most people are ill informed and have no conception of what the Internet is or how it works. Nor do they care. They just want to go access information from so and so site and don't care that the information they want forces you to allow traffic to pass between your network and a network that doesn't handle abuse@ complaints, keeps a poor rwhois database, allows customers to be signed up with falsified POCs for IP assignment as well as domain assignment, and trashes your servers with garbage such as spam knowingly. A community would imply people of like mind and collaboration. Yet it is the people who know the least that are making the demands. -Jack
At 05:46 PM 1/30/2003 -0800, Dave Crocker wrote:
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.
A large chunk of the spam I am seeing these days are due to exploitable formmail.pl scripts (i.e. insecure customer web apps) and open proxies (1080,8080 3128 etc). These forms of delivery are also preferred by spammers as their original IP addresses are hidden. Blocking port 25 will do nothing to stop this. I would be surprised if your premise holds true, that the majority of the Ops community support this. Blocking port 25 results in lost customers as well as additional support headaches. I know when the local big ISP (Sympatico) starting blocking port 25, we gained quite a few business customers. So our sales staff certainly supported their Ops implementing it. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
It's a rare day when I differ with Dave over mail standards, so something's weird. Dave Crocker wrote:
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.
The submission port, according to IANA is 587. I'm not a fan. I also think experience has shown that it is POSSIBLE to protect port 25 appropriately. It's just a matter of doing it... See http://www.iana.org/assignments/port-numbers
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).
Although Dave is correct about SSL, RFC 3207 discusses the use of TLS for purposes of encryption AND authentication. I use this for my own sendmail. The biggest problem is ensuring that appropriate certificates are installed. Most of the common MUAs I tested have a way to do it, but it's messy (to say the least). Eliot
At 10:25 PM 1/30/2003, Eliot Lear wrote:
It's a rare day when I differ with Dave over mail standards, so something's weird.
Dave Crocker wrote:
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.
The submission port, according to IANA is 587. I'm not a fan. I also think experience has shown that it is POSSIBLE to protect port 25 appropriately. It's just a matter of doing it...
I am a fan of port 587 being a viable alternative, as it provides a way for our customers who are blocked on port 25 to send their email through our servers (with SMTP AUTH or SMTP-after-POP). If this is going to be the norm from now on, it'd sure be nice if the MUAs had an automated way to set up users to use the SUBMISSION port. It'd also be nice if a certain large vendor fixed their MUA to understand STARTTLS and properly implemented it. Port 25 blocking, especially on dialups, did for a time cut down on the spam levels. This benefit has largely disappeared as the spammers now use open proxies found all over the 'net.
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).
Although Dave is correct about SSL, RFC 3207 discusses the use of TLS for purposes of encryption AND authentication. I use this for my own sendmail. The biggest problem is ensuring that appropriate certificates are installed. Most of the common MUAs I tested have a way to do it, but it's messy (to say the least).
We encourage our users to use STARTTLS, but they're using username/password for the SMTP AUTH (and the POP auth) rather than client certs.
Eliot, Thursday, January 30, 2003, 7:25:05 PM, you wrote: EL> The submission port, according to IANA is 587. Sorry about that detail. I searched the IANA port assignment file for 'submit' rather than 'submission'. Luckily, the error does not affect the core concern I am raising. EL> I'm not a fan. I also EL> think experience has shown that it is POSSIBLE to protect port 25 EL> appropriately. It's just a matter of doing it... EL> See http://www.iana.org/assignments/port-numbers Recently I had protracted discussions with a number of Ops folks about this issue and have chosen to drop that debate. I do not agree with blocking port 25, either, but am far more concerned about having a coherent, workable means of remote access than I am about it being the particular one I prefer. As long as it is technically adequate and supported broadly (ie, predictably) by service providers and software providers, the details frankly do not matter to me.
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).
EL> Although Dave is correct about SSL, RFC 3207 discusses the use of TLS EL> for purposes of encryption AND authentication. I use this for my own EL> sendmail. The biggest problem is ensuring that appropriate certificates EL> are installed. Most of the common MUAs I tested have a way to do it, EL> but it's messy (to say the least). Thanks for the clarification. Unfortunately it mostly means there are even more choices to make and, therefore, less predictability and, therefore, less interoperability at Internet scale. d/ -- Dave <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850
We need to narrow down the recommended choices, preferably to one per service.
I'm seeing a lot of SMTP-AUTH and pop-before-smtp (which can easily coexist on the same server) on port 587. Current versions of popular MTAs all seem to support at least one of those, albeit sometimes not very conveniently. It would be nice if we could use SMTP-AUTH on port 25, but the spammers ruined that for us around the same time they ruined courtesy relay. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
On 4 Feb 2003, John R. Levine wrote:
It would be nice if we could use SMTP-AUTH on port 25, but the spammers ruined that for us around the same time they ruined courtesy relay.
How did they ruin SMTP Auth? Thanks. andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp
It would be nice if we could use SMTP-AUTH on port 25, but the spammers ruined that for us around the same time they ruined courtesy relay.
How did they ruin SMTP Auth? Thanks.
They made it impossible to use port 25 at all, since it's impractical for ISPs to sniff outgoing traffic to permit SMTP AUTH connections and block others, and way too much of the other port 25 traffic was direct-from-dialup spam. SMTP AUTH works fine on port 587, since there should be no traffic to that port that isn't authenticated somehow. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web
participants (9)
-
Andy Walden -
Daniel Senie -
Dave Crocker -
Dave Crocker -
Eliot Lear -
Jack Bates -
John R Levine -
johnl＠iecc.com
-
Mike Tancsa