Although RFC2476 was published in December 1998, its amazing how few mail providers support the Message Submission protocol for e-mail on Port 587. Even odder, some mail providers use other ports such as 26 or 2525, but not the RFC recommended Port 587 for remote authenticated mail access for users. Large mail providers like AOL, GMAIL and Yahoo support authenticated mail on port 587; and some also support Port 465 for legacy SMTP/SSL. But a lot of universities and smaller mail providers don't. They still use SMTP Port 25 for roaming users. With AT&T, Earthlink, COX, Netzero and other ISPs filtering port 25 for years, I would have thought most mail providers would have started supporting Port 587 by now. What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587? What can be done to encourage the mail client software programers (i.e. Outlook, Eudora, etc) to make Port 587 the default (or at least the first try) and let the user change it back to port 25 (or automatically fallback) if they are still using a legacy mail server. Sendmail now includes Port 587, although some people disagree how its done. But Exchange and other mail servers are still difficult for system administrators to configure Port 587 (if it doesn't say click here for Port 587 during the Windows installer, its too complicated).
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Sendmail now includes Port 587, although some people disagree how its done. But Exchange and other mail servers are still difficult for system administrators to configure Port 587 (if it doesn't say click here for Port 587 during the Windows installer, its too complicated).
This is utterly silly. Running another full-access copy of the MTA on a different port than 25 achieves precisely nothing -- and this "support" has always been included in sendmail, with a 1-line change either to the source code (long ago) or the default configuration or simply by running sendmail from inetd. What benefit, exactly, do you see to allowing unauthenticated mail submission on a different port than the default SMTP port? Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25? What will actually give us some progress on spam and on usability issues is requiring authentication for mail submission. Which TCP port is used for the service matters basically not at all. Thor
On Wed, Feb 16, 2005, Thor Lancelot Simon wrote:
Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25?
because then you can filter port 25 access to anywhere except your local mailserver, like we do here on campus, and suggest to people they use a VPN or Authenticated SMTP to port 587 to their ISP or company when they wish to use an external mail server. Quite useful when it works (read: the other party has implemented AUTH-SMTP on port 587). adrian -- Adrian Chadd "You don't have a TV? Then what's <adrian@creative.net.au> all your furniture pointing at?"
On Wed, Feb 16, 2005 at 02:23:04AM +0000, Adrian Chadd wrote:
Quite useful when it works (read: the other party has implemented AUTH-SMTP on port 587).
And if they's implemented unauthenticated SMTP on port 587, like, say, Sendmail, you've achieved nothing, or possibly worse, since you have encouraged people to simply run open relays on a different port than 25. How long do you think it's going to take for spammers to take advantage of this? (That's a rhetorical question: I already see spam engines trying to open port 587 connections in traces). Slavishly changing ports isn't the solution. Actually using authentication is the solution. It is silly -- to say the least -- to confuse the benefits of the two. Thor
On 2/15/05 9:36 PM, "Thor Lancelot Simon" <tls@NetBSD.org> wrote:
On Wed, Feb 16, 2005 at 02:23:04AM +0000, Adrian Chadd wrote:
Quite useful when it works (read: the other party has implemented AUTH-SMTP on port 587).
And if they's implemented unauthenticated SMTP on port 587, like, say, Sendmail, you've achieved nothing, or possibly worse, since you have encouraged people to simply run open relays on a different port than 25. How long do you think it's going to take for spammers to take advantage of this? (That's a rhetorical question: I already see spam engines trying to open port 587 connections in traces).
Slavishly changing ports isn't the solution. Actually using authentication is the solution. It is silly -- to say the least -- to confuse the benefits of the two.
Thor
Thor, I don't think anyone is confusing the benefits. Sean's suggestion was quite clear. Run SMTP-Auth on port 587 and leave port 25 for email from other mail servers. There are lots of benefits to this approach. For one thing, it eliminates a lot of the "reasons" for provider email smarthosting, which needs to go away due to massive abuse. Sender email authentication will make smarthosting obsolete and users will need a different way of sending outgoing mail that isn't spam to their own mail servers for legitimate relay. ISPs filter port 25 outbound, but leave 587 open with the idea that users would have to authenticate against distant mail servers on that port. Everything works well. 587 running SMTP auth (and relaying for authenticated users) and port 25 for local (non relay) delivery without authentication should be the default on all servers. -- Daniel Golding Network and Telecommunications Strategies Burton Group
On Tue, 15 Feb 2005 21:50:23 -0500, Daniel Golding <dgolding@burtongroup.com> wrote:
Thor,
587 running SMTP auth (and relaying for authenticated users) and port 25 for local (non relay) delivery without authentication should be the default on all servers.
Agreed! At the very least you get the benefit of an electronic trail to follow if one of your users *is* spamming.. :) If you only relay mail from authenticated users, drop (not bounce) any mail destined for a non-existant account, and use reasonable spam blocking and tagging, you should be able to reduce spam to a slow trickle.. It's working here, thus far... And I don't have authentication fully implemented yet. :)
-- Daniel Golding Network and Telecommunications Strategies Burton Group
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com
Um, you actually have to work somewhat to get sendmail to support unauthenticated submission on port 587. The default configuration is that port 25 is unauthenticated (albeit with some restrictions on relaying (only for local clients)) and port 587 is authenticated. As such, I'm not sure why you seem to think that sendmail on port 587 is unauthenticated. Sure, spammers will try anything that might work. However, for the moment, 587 is a reasonable pragma. Unauthenticated relays on 587 should definitely be blocked no questions asked. It's not that clear cut for 25. Owen --On Wednesday, February 16, 2005 2:36 +0000 Thor Lancelot Simon <tls@netbsd.org> wrote:
On Wed, Feb 16, 2005 at 02:23:04AM +0000, Adrian Chadd wrote:
Quite useful when it works (read: the other party has implemented AUTH-SMTP on port 587).
And if they's implemented unauthenticated SMTP on port 587, like, say, Sendmail, you've achieved nothing, or possibly worse, since you have encouraged people to simply run open relays on a different port than 25. How long do you think it's going to take for spammers to take advantage of this? (That's a rhetorical question: I already see spam engines trying to open port 587 connections in traces).
Slavishly changing ports isn't the solution. Actually using authentication is the solution. It is silly -- to say the least -- to confuse the benefits of the two.
Thor
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
On Wed, 16 Feb 2005 01:46:09 PST, Owen DeLong said:
--==========04787AC3A7FDFBF67AA5========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Um, you actually have to work somewhat to get sendmail to support unauthenticated submission on port 587. The default configuration is that port 25 is unauthenticated (albeit with some restrictions on relaying (only for local clients)) and port 587 is authenticated.
As such, I'm not sure why you seem to think that sendmail on port 587 is unauthenticated.
Umm.. because the Sendmail 8.13.3 tree has this: (from cf/README): ---- If DAEMON_OPTIONS is not used, then the default is DAEMON_OPTIONS(`Port=smtp, Name=MTA') DAEMON_OPTIONS(`Port=587, Name=MSA, M=E') ---- from doc/op/op.me: That is, one way to specify a message submission agent (MSA) that always requires authentication is: .(b O DaemonPortOptions=Name=MSA, Port=587, M=Ea .)b Hmm.. no default 'a' to require authentication by default. That would probably explain why you actually have to work to set it up.
On Wed, 16 Feb 2005 Valdis.Kletnieks@vt.edu wrote:
Um, you actually have to work somewhat to get sendmail to support unauthenticated submission on port 587. The default configuration is that port 25 is unauthenticated (albeit with some restrictions on relaying (only for local clients)) and port 587 is authenticated.
As such, I'm not sure why you seem to think that sendmail on port 587 is unauthenticated.
Umm.. because the Sendmail 8.13.3 tree has this:
DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')
Yup. I posted to another NANOG thread a little while ago about when I mentioned this failure of security to the Sendmail folks and was shot down voraciously by Claus and argued into oblivion by Neil. They don't see this as a security threat for some blissfully ignorant reason. I'm still sitting on a m4 patch that, by default, disallows MSA submission from any party not also permitted to *relay* (this means that IP list based auth works, not just SMTP AUTH). It uses a new DaemonPortOptions flag, and adds three ruleset lines. Here's the actual message in which I proposed this and provided the diff. The only thing missing here is one more op.me doc fix, but it's fuctionally correct. The patch still works on 8.13.x. ===== Date: Wed, 16 Jun 2004 22:29:12 -0400 (EDT) From: Todd Vierling <tv@duh.org> To: sendmail@sendmail.org Subject: MSA-not-like-MTA diff deux On Wed, 16 Jun 2004, Neil W Rickert wrote:
Relay permission is already logically necessary for legitimate users of the MSA port, so this aspect can and should be enforced as mandatory.
If "Relay permission is already logically necessary" then what we are already doing must meet your requirements.
Except that currently, the following part is not enforced:
3. MTAs should never contact the MSA port for anonymous mail delivery injection.
because remote systems are indeed being allowed to inject mail anonymously, so long as the RHS of the RCPT TO is "local".
You would have done better to just submit a patch with a brief explanation, and without the bogus claim that there is a security hole.
Those of us who are deluged by a flood by wormspew, and fighting back against it fiercely, consider this to be a huge security hole. Sendmail is [when using the default out-of-the-box settings] allowing at least one worm so far to propagate beyond the realm of port-25 filtering. This is why I started by asking a question about it in a security context, and was rather taken aback by what appeared (to me) to be denial of the problem's existence. Rather, it only appears to be that the members of the Sendmail author team haven't -- yet -- seen the detrimental effects of a MTA-as-MSA port to quite the degree that some others of us already have. I apologize for my misinterpretation. To level the issue a bit:
Maybe at this stage you should extend the patch to cover the documentation (cf/README and maybe doc/op/op.me (for the proposed new modifier for DaemonPortOptions). Then resubmit and see what Claus decides to do with it.
Attached below. Diff is against 8.12.11. I used modifier `L' as a "not Local" meaning, given that the other uppercase letters mean "not Something", but maybe that's not so intuitive?[*] If you think it should use a different option letter, let me know and I'll re-roll the diff. [*] As if rulesets are intuitive. But then, I did write a text search algo in m4 some ages ago.... 8-) ===== --- doc/op/op.me.orig Wed Jun 16 22:01:02 2004 +++ doc/op/op.me Wed Jun 16 22:11:05 2004 @@ -6457,11 +6457,15 @@ A disable AUTH (overrides 'a' modifier) C don't perform hostname canonification E disallow ETRN (see RFC 2476) +L treat all mail as nonlocal; require relay permission (.cf) O optional; if opening the socket fails ignore it S don't offer STARTTLS .)b -That is, one way to specify a message submission agent (MSA) that -always requires authentication is: +The standard message submission agent (MSA) uses the ``L'' +modifier to restrict message submission only to clients that have +mail relaying permission. +A way to specify a message submission agent (MSA) that +always requires SMTP AUTH based authentication is: .(b O DaemonPortOptions=Name=MSA, Port=587, M=Ea .)b @@ -6471,8 +6475,8 @@ .b ${daemon_flags} . Notice: Do .b not -use the ``a'' modifier on a public accessible MTA! -It should only be used for a MSA that is accessed by authorized +use the ``a'' and/or ``L'' modifiers on a publicly accessible MTA! +They should only be used for a MSA that is accessed by authorized users for initial mail submission. Users must authenticate to use a MSA which has this option turned on. The flags ``c'' and ``C'' can change the default for --- cf/m4/proto.m4.orig Sun Jan 11 12:54:06 2004 +++ cf/m4/proto.m4 Wed Jun 16 22:00:47 2004 @@ -347,7 +347,7 @@ ifelse(defn(`_DPO_'), `', `ifdef(`_NETINET6_', `O DaemonPortOptions=Name=MTA-v4, Family=inet O DaemonPortOptions=Name=MTA-v6, Family=inet6',`O DaemonPortOptions=Name=MTA')', `_DPO_') -ifdef(`_NO_MSA_', `dnl', `O DaemonPortOptions=Port=587, Name=MSA, M=E') +ifdef(`_NO_MSA_', `dnl', `O DaemonPortOptions=Port=587, Name=MSA, M=EL') # SMTP client options ifelse(defn(`confCLIENT_OPTIONS'), `', `dnl', @@ -2041,6 +2041,10 @@ ifelse(defn(`_NO_UUCP_'), `r', `R$* ! $* < @ $* > $: <REMOTE> $2 < @ BANG_PATH > R$* ! $* $: <REMOTE> $2 < @ BANG_PATH >', `dnl') +# do not implicitly trust local recipients on MSA port(s) +R$* $: $&{daemon_flags} $| $1 +R$* LL $* $| $* $@ NO +R$* $| $* $: $2 # anything terminating locally is ok ifdef(`_RELAY_ENTIRE_DOMAIN_', `dnl R$+ < @ $* $=m > $@ RELAY', `dnl') --- cf/README.orig Wed Jun 16 21:58:42 2004 +++ cf/README Wed Jun 16 21:59:46 2004 @@ -1345,7 +1345,7 @@ follow the colon. no_default_msa Don't generate the default MSA daemon, i.e., - DAEMON_OPTIONS(`Port=587,Name=MSA,M=E') + DAEMON_OPTIONS(`Port=587,Name=MSA,M=EL') To define a MSA daemon with other parameters, use this FEATURE and introduce new settings via DAEMON_OPTIONS(). @@ -4055,7 +4055,7 @@ If DAEMON_OPTIONS is not used, then the default is DAEMON_OPTIONS(`Port=smtp, Name=MTA') - DAEMON_OPTIONS(`Port=587, Name=MSA, M=E') + DAEMON_OPTIONS(`Port=587, Name=MSA, M=EL') If you use one DAEMON_OPTIONS macro, it will alter the parameters of the first of these. The second will still be defaulted; it @@ -4072,7 +4072,7 @@ using the default SMTP port, use FEATURE(`no_default_msa') DAEMON_OPTIONS(`Name=MTA') - DAEMON_OPTIONS(`Port=987, Name=MSA, M=E') + DAEMON_OPTIONS(`Port=987, Name=MSA, M=EL') Note that if the first of those DAEMON_OPTIONS lines were omitted, then there would be no listener on the standard SMTP port. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
Chances are that the Sendmail team doesn't share your worm problems as most of them are not likely running unpatched windows boxes. Owen
On Thu, 17 Feb 2005, Owen DeLong wrote:
Chances are that the Sendmail team doesn't share your worm problems as most of them are not likely running unpatched windows boxes.
You don't have to run Windowz systems to get hit by their blowback. And that's the problem, in a nutshell.... -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On Wed, 16 Feb 2005, Thor Lancelot Simon wrote:
This is utterly silly. Running another full-access copy of the MTA on a different port than 25 achieves precisely nothing -- and this "support" has always been included in sendmail, with a 1-line change either to the source code (long ago) or the default configuration or simply by running sendmail from inetd.
What benefit, exactly, do you see to allowing unauthenticated mail submission on a different port than the default SMTP port?
Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25?
How do you tell the difference. Yes, you can run any protocol on any port. But Well-known ports have a better chance of working across today's Internet full of NAT and firewalls. By keeping authenticated and unauthenticated protocols on different ports, its easier to control the use of unauthenticated protocols at various middle-points in the network without affecting people using authenticated protocols. Port 25 accepts unauthenticated e-mail for various legacy reasons, which are not going to go away soon. Port 587 is supposed to be authenticated, although some programmers and system administrators think its too hard to ask for authentication. If you accept unauthenticated mail on Port 587, don't complain about the spam you are going to get.
What will actually give us some progress on spam and on usability issues is requiring authentication for mail submission. Which TCP port is used for the service matters basically not at all.
In theory true, you could run a TELNET listener on Port 25 or 135. But the world works a bit better when most people follow the same practice. Port 587 is for authenticated mail message submission.
On Tue, Feb 15, 2005 at 09:30:18PM -0500, Sean Donelan wrote:
In theory true, you could run a TELNET listener on Port 25 or 135. But the world works a bit better when most people follow the same practice. Port 587 is for authenticated mail message submission.
I'm sorry, your last message seemed to indicate that you felt that Sendmail accepting unauthenticated mail on port 587 (if configured to accept unauthenticated mail at all) was not a problem; that, somehow, it was a *good* thing that it would happily apply the same policy to all ports it listened on, so long as one of those ports was 587. Is that not, in fact, your position? It is really hard for me to see encouraging people to run additional unauthenticated mail servers on some other port as a good idea, and it is really hard for me to read the actual text in your first message any other way than simply "mail accepted on port 587 good". Thor
--On Tuesday, February 15, 2005 21:30 -0500 Sean Donelan <sean@donelan.com> wrote:
On Wed, 16 Feb 2005, Thor Lancelot Simon wrote:
This is utterly silly. Running another full-access copy of the MTA on a different port than 25 achieves precisely nothing -- and this "support" has always been included in sendmail, with a 1-line change either to the source code (long ago) or the default configuration or simply by running sendmail from inetd.
What benefit, exactly, do you see to allowing unauthenticated mail submission on a different port than the default SMTP port?
Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25?
How do you tell the difference. Yes, you can run any protocol on any port. But Well-known ports have a better chance of working across today's Internet full of NAT and firewalls. By keeping authenticated and unauthenticated protocols on different ports, its easier to control the use of unauthenticated protocols at various middle-points in the network without affecting people using authenticated protocols.
Port 25 accepts unauthenticated e-mail for various legacy reasons, which are not going to go away soon.
Port 587 is supposed to be authenticated, although some programmers and system administrators think its too hard to ask for authentication.
I would argue that in today's environment, a well implemented mailserver supports authenticated submission on ports 25 and 587, and, unauthenticated delivery on port 25. It may also support some level of unauthenticated submission by local users on port 25, if necessary.
If you accept unauthenticated mail on Port 587, don't complain about the spam you are going to get.
If you accept unauthenticated mail on port 587, the problem isn't the spam you will receive, it is the spam you will forward. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
At 04:42 AM 2/16/2005, Owen DeLong <owen@delong.com> wrote:
If you accept unauthenticated mail on port 587, the problem isn't the spam you will receive, it is the spam you will forward.
ONLY if that unauthenticated sender is also permitted to RELAY. That is not a given. The decision to relay or not is separate from whether the user is authenticated with SMTP AUTH or some other method (IP address range, smtp-after-pop), just as it is on port 25. I'm not arguing for leaving port 587 wide open, but there are uses to allowing potr 587 and 25 to have the same rules, and not permit relay on either. This is necessary where SMTP-after-POP is still in use, for example, but does NOT imply open relay. Yes, authorized users (authorized by AUTH, smtp-after-pop, or IP address ranges) can still send mail (including spam, subject to enforcement) but that does NOT constitute open relay.
Thor Lancelot Simon wrote:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Sendmail now includes Port 587, although some people disagree how its done. But Exchange and other mail servers are still difficult for system administrators to configure Port 587 (if it doesn't say click here for Port 587 during the Windows installer, its too complicated).
This is utterly silly. Running another full-access copy of the MTA on a different port than 25 achieves precisely nothing -- and this "support" has always been included in sendmail, with a 1-line change either to the source code (long ago) or the default configuration or simply by running sendmail from inetd.
What benefit, exactly, do you see to allowing unauthenticated mail submission on a different port than the default SMTP port?
Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25?
What will actually give us some progress on spam and on usability issues is requiring authentication for mail submission. Which TCP port is used for the service matters basically not at all.
In general, I have agreed with your point of view in the past. I will say, however, that recently I have slightly retraced my position. The only real benefit I see from it is that running multiple ports allows the mail server to provide different policies for clients to use. Ideally, this shouldn't be needed, but given that some mail client software doesn't allow the configuration options that are needed in some situations (Apple's Mail.app absolutely infuriates me at times), there are times that slightly different policies are needed, and the only really good way to do that is to run them on different ports. I guess you could think of it as having port 25 available for legacy support as more and more stuff moves to 587. authentication for mail submission would be wonderful if it were ubiquitous...and I'm doing my part (this message, and all others from me these days submitted to my ISP's system with SMTP AUTH over TLS...incidentally, they had to configure 587 in order to get the policies workable for the variety of mail clients that customers used...sad but true, they had no choice while maintaining any semblance of varied client support), alas, that day is still fairly far off...though it is getting closer. -- Jeff
Thor Lancelot Simon wrote:
What benefit, exactly, do you see to allowing unauthenticated mail submission on a different port than the default SMTP port?
The relevant RFC says that port 587 must be used for authenticated connections ONLY.
Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25?
I think the idea was that Port 25 must also allow unauthenticated connections from foreign MTAs. Port 587 is designed to be used only to relay mail for authenticated users of the server in question, because outgoing Port 25 connections are so widely blocked by large ISPs.
What will actually give us some progress on spam and on usability issues is requiring authentication for mail submission.
That's the way it's *supposed* to work now. What actually will give us progress on spam is a complete rewriting of the SMTP protocol, but quite frankly, I'm not holding my breath. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "In case anyone was wondering, that big glowing globe above the Victor Valley is the sun." -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)
--On Wednesday, February 16, 2005 2:16 +0000 Thor Lancelot Simon <tls@netbsd.org> wrote:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Sendmail now includes Port 587, although some people disagree how its done. But Exchange and other mail servers are still difficult for system administrators to configure Port 587 (if it doesn't say click here for Port 587 during the Windows installer, its too complicated).
This is utterly silly. Running another full-access copy of the MTA on a different port than 25 achieves precisely nothing -- and this "support" has always been included in sendmail, with a 1-line change either to the source code (long ago) or the default configuration or simply by running sendmail from inetd.
What benefit, exactly, do you see to allowing unauthenticated mail submission on a different port than the default SMTP port?
The whole point of port 587 is that it should _NOT_ allow unauthenticated submission, where, port 25 generally MUST allow unauthenticated submission for at least some categories of destination addresses. If port 25 only gets used for MTA to MTA communications and port 587 can be used for CLIENT->MTA submissions on an authenticated only basis, there is some advantage to it. Admittedly, port 587 would be unnecessary if ISPs weren't blocking port 25, but, since they are, it is. Likely, if people started requiring SMTP AUTH often enough on port 25 for relay access, the port 25 blocks could be eliminated and port 587 could fade away. However, in the meantime, port 687 is a reasonable solution to the real world situation.
Similarly, what harm, exactly, do you see to allowing authenticated mail submission on port 25?
None. However, it's very hard to control at the router level whether your thousands of DSL users are making authenticated submission or non-authenticated submission to far-end mail servers. By blocking port 25 and knowing that almost anyone using 587 is probably recently enough up on RFCs to know not to allow unauthenticated submission, this becomes a reasonable compromise. Everyone requiring auth on port 25 for relay submission would be a better solution, but, is also an unrealistic view of the world.
What will actually give us some progress on spam and on usability issues is requiring authentication for mail submission. Which TCP port is used for the service matters basically not at all.
Yep, but, if we block virus->25 and support auth->587, then, we aren't allowing virus->25 by accident in the current environment. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
Thor Lancelot Simon wrote:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Sendmail now includes Port 587, although some people disagree how its done. But Exchange and other mail servers are still difficult for system administrators to configure Port 587 (if it doesn't say click here for Port 587 during the Windows installer, its too complicated).
This is utterly silly. Running another full-access copy of the MTA on a different port than 25 achieves precisely nothing
I think we have ignored/trivialized the obvious. Port 587 gives you the ability to class your connections as either MTA<->MTA, Legacy User->MTA, MSP User ->MTA. This is quite valuable as you now have the theoretical ability treat them differently. Whether that means different access/authentication/encryption/firewall/relay policies or whatever. If all one does is run a full copy on that port then *THEY* have gained almost nothing in practice, aside from further un-exploited capabilities. However we all gain from ever increasing, even if it is only incremental, support of well known RFC's. Specific MTA discussions aside, port 587 is a good thing, and the more of it the merrier.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thor Lancelot Simon wrote: | On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote: | |>Sendmail now includes Port 587, although some people disagree how |>its done. But Exchange and other mail servers are still difficult |>for system administrators to configure Port 587 (if it doesn't say |>click here for Port 587 during the Windows installer, its too |>complicated). | | | This is utterly silly. Running another full-access copy of the MTA | on a different port than 25 achieves precisely nothing -- Actually, it achives a number of things. First that comes to mind is to allow road-warriors to establish tls conections with the home mta by side-stepping hote and hotspot style mta proxies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCE1/A0STXFHxUucwRAnzPAJ9dqTukhoF7fNpzZjTMAqRe7DunoQCaApJw h0/sB5P5205mmBp/+ZNfO4k= =G/2V -----END PGP SIGNATURE-----
At 09:00 PM 2/15/2005, you wrote:
Although RFC2476 was published in December 1998, its amazing how few mail providers support the Message Submission protocol for e-mail on Port 587. Even odder, some mail providers use other ports such as 26 or 2525, but not the RFC recommended Port 587 for remote authenticated mail access for users.
Large mail providers like AOL, GMAIL and Yahoo support authenticated mail on port 587; and some also support Port 465 for legacy SMTP/SSL. But a lot of universities and smaller mail providers don't.
Lots of small companies support these as well, including hosting companies and smaller ISPs, and have done so for 5 or 6 years.
They still use SMTP Port 25 for roaming users. With AT&T, Earthlink, COX, Netzero and other ISPs filtering port 25 for years, I would have thought most mail providers would have started supporting Port 587 by now.
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Get the software developers to do some useful programming.
What can be done to encourage the mail client software programers (i.e. Outlook, Eudora, etc) to make Port 587 the default (or at least the first try) and let the user change it back to port 25 (or automatically fallback) if they are still using a legacy mail server.
Don't forget enabling SMTP AUTH by default. Microsoft seems to only support SMTPS and POPS (alternate ports). Eudora finally supports TLS reasonably well now that they switched to using OpenSSL. While Eudora can be configured for port 587, it takes some doing, since users have to install the esoteric settings menu plugin or edit a config file. It'd be nice if the new account wizards actually got this stuff right. We give customers a document that walks them through the wizard, then walks them through fixing the things the wizard didn't do.
Sendmail now includes Port 587, although some people disagree how its done.
The configs for sendmail that come with RedHat have it listening only to 127.0.0.1 by default. The config file (.mc) has a good config line for port 587 documented and commented out. They also have a port 465 example, which has encryption required, but not AUTH. Is the proper configuration or proper examples the responsibility of sendmail developers, those packaging sendmail with systems, or those who deploy the software?
Daniel Senie wrote:
Is the proper configuration or proper examples the responsibility of sendmail developers, those packaging sendmail with systems, or those who deploy the software?
The correct answer is "those who deploy the software," regardless of whether it's a mail server, firewall, IP router,* or any other type of software. *I had to say that; this *is* NANOG. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "In case anyone was wondering, that big glowing globe above the Victor Valley is the sun." -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)
Yet another reason for supporting port 587 on your servers for remote authenticated mail submission from your users. If you don't support port 587, and use SPF, it may break when AOL or other providers re-direct port 25. http://www.heise.de/english/newsticker/news/56437
with many questions related to this topic." The company was advising AOL customers affected to switch to message submission port 587, the signals from which were not being filtered by AOL, the spokesman said. This item of advice on switching coincides with that given by AOL itself. Not all mail providers accept messages from this port, however; and not every mail client allows users to freely select their SMTP port.
* Sean Donelan:
Yet another reason for supporting port 587 on your servers for remote authenticated mail submission from your users. If you don't support port 587, and use SPF, it may break when AOL or other providers re-direct port 25.
Has AOL notified anyone in advance? Quite a few provider-independent mail providers were caught by surprise.
On 02/19/05, Florian Weimer <fw@deneb.enyo.de> wrote:
* Sean Donelan:
Yet another reason for supporting port 587 on your servers for remote authenticated mail submission from your users. If you don't support port 587, and use SPF, it may break when AOL or other providers re-direct port 25.
Has AOL notified anyone in advance? Quite a few provider-independent mail providers were caught by surprise.
Is there a mailing list that will reach all/most of these provider-independent mail providers? (If so, then that's where we should be having this discussion asking why they don't support port 587 yet.) -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
On Sat, 19 Feb 2005, J.D. Falk wrote:
Has AOL notified anyone in advance? Quite a few provider-independent mail providers were caught by surprise.
Is there a mailing list that will reach all/most of these provider-independent mail providers?
(If so, then that's where we should be having this discussion asking why they don't support port 587 yet.)
If there was a forum read by all/most of those provider-independent mail providers, that would be great. NANOG is one of the most widely read network operations mailing lists on the network. That is why items such as IANA assignments, root server changes, wide-scale outages are posted here. There are more specific mailing lists for some subjects, but they tend to be read by people who are already familar with the subject. The problem is how do reach people who don't read such lists and aren't familar with the subject. If you look through many different mailing list archives for the last eight years, you will find many different providers blocking port 25 and recommending support for port 587. And you will find people being "surprised" by the changes, or who knew about the changes but didn't do anything until they were personally affected.
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Although RFC2476 was published in December 1998, its amazing how few mail providers support the Message Submission protocol for e-mail on Port 587. Even odder, some mail providers use other ports such as 26 or 2525, but not the RFC recommended Port 587 for remote authenticated mail access for users.
I can not say anything about other providers, but I don't do it for a simple reason: I think it is completely pointless.
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part. Nils
* Nils Ketelsen:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
From the MTA perspective, 25/TCP is the "you are responsible for the message" port, 587/TCP is the "I will be responsible for the message" port. In other words, the implied abuse management contracts differ significantly.
However, this is mostly theory. I'm not sure if mail providers will try to pass responsibility for spam injected on 587/TCP to the ISP from whose address space the message was submitted. (They already do so for some parts of the abuse management process, e.g. law enforcement requests.)
On Thu, 24 Feb 2005 16:08:42 EST, Nils Ketelsen said:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
If you're a roaming user from that provider, and you're at some other site that blocks or hijacks port 25, you can still send mail by tossing it to your main provider's 587. If that's not a good enough reason to motivate the provider to support it, nothing will (except maybe when the users show up en masse with pitchforks and other implements of destruction...)
On Thu, Feb 24, 2005 at 04:20:33PM -0500, Valdis.Kletnieks@vt.edu wrote:
On Thu, 24 Feb 2005 16:08:42 EST, Nils Ketelsen said:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587? Give a good reason. That is still the missing part.
If you're a roaming user from that provider, and you're at some other site that blocks or hijacks port 25, you can still send mail by tossing it to your main provider's 587. If that's not a good enough reason to
And if I am a roaming user at some other site, that blocks or hijacks port 587?
motivate the provider to support it, nothing will (except maybe when the users show up en masse with pitchforks and other implements of destruction...)
Then, I believe, nothing will motivate me. Nils
On Thu, 24 Feb 2005 16:40:05 EST, Nils Ketelsen said:
And if I am a roaming user at some other site, that blocks or hijacks port 587?
Can anybody point at any ISP that actually does hijack port 587? (Yes, it's quite possible that if you're visiting and on a corporate net as a consultant or similar, that you can't get out on 587 - but we're talking ISPs, universities, and other "mostly open" connectivity providers...)
owner-nanog@merit.edu wrote:
On Thu, 24 Feb 2005 16:08:42 EST, Nils Ketelsen said:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
If you're a roaming user from that provider, and you're at some other site that blocks or hijacks port 25, you can still send mail by tossing it to your main provider's 587. If that's not a good enough reason to motivate the provider to support it, nothing will (except maybe when the users show up en masse with pitchforks and other implements of destruction...)
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing? Andrew
andrew2@one.net wrote:
owner-nanog@merit.edu wrote:
On Thu, 24 Feb 2005 16:08:42 EST, Nils Ketelsen said:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
If you're a roaming user from that provider, and you're at some other site that blocks or hijacks port 25, you can still send mail by tossing it to your main provider's 587. If that's not a good enough reason to motivate the provider to support it, nothing will (except maybe when the users show up en masse with pitchforks and other implements of destruction...)
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing?
Andrew
What man hours? Thats the default setup for most sendmails!
If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave the rest alone? -Jim P. On Thu, 2005-02-24 at 16:51 -0500, andrew2@one.net wrote:
owner-nanog@merit.edu wrote:
On Thu, 24 Feb 2005 16:08:42 EST, Nils Ketelsen said:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
If you're a roaming user from that provider, and you're at some other site that blocks or hijacks port 25, you can still send mail by tossing it to your main provider's 587. If that's not a good enough reason to motivate the provider to support it, nothing will (except maybe when the users show up en masse with pitchforks and other implements of destruction...)
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing?
Andrew
On Thu, 2005-02-24 at 17:14 -0500, Jim Popovitch wrote:
If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave the rest alone?
I did run into a case where supporting port 587 was useful. I found out the hard way that one Internet service provider for hotels blocked outbound port 25, but not 587. So sending outbound mail to my mail relay would have been impossible without support for port 587. -- Smoot Carl-Mitchell System/Network Architect email: smoot@tic.com cell: +1 602 421 9005 home: +1 480 922 7313
On Thu, Feb 24, 2005 at 04:02:20PM -0700, Smoot Carl-Mitchell wrote:
If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave the rest alone? I did run into a case where supporting port 587 was useful. I found out
On Thu, 2005-02-24 at 17:14 -0500, Jim Popovitch wrote: the hard way that one Internet service provider for hotels blocked outbound port 25, but not 587. So sending outbound mail to my mail relay would have been impossible without support for port 587.
It's so funny. On this list many argued Port 25 outgoing must be blocked only to notice, that users actually seem to need it to send mail. Now we must configure our mailservers to listen on 587 to circumvent these filters, that were stupid in the first place. Now to my prophecy mode: Spammers will start using 587 to spam, which we then also all block outgoing, notice again that customers still want to send mail and open another port ... 652 maybe. But this in a "while (true)" loop until we run out of ports. This is completely ridiculous. Nils
owner-nanog@merit.edu wrote:
On Thu, Feb 24, 2005 at 04:02:20PM -0700, Smoot Carl-Mitchell wrote:
If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave
On Thu, 2005-02-24 at 17:14 -0500, Jim Popovitch wrote: the rest alone? I did run into a case where supporting port 587 was useful. I found out the hard way that one Internet service provider for hotels blocked outbound port 25, but not 587. So sending outbound mail to my mail relay would have been impossible without support for port 587.
It's so funny. On this list many argued Port 25 outgoing must be blocked only to notice, that users actually seem to need it to send mail. Now we must configure our mailservers to listen on 587 to circumvent these filters, that were stupid in the first place.
Now to my prophecy mode: Spammers will start using 587 to spam, which we then also all block outgoing, notice again that customers still want to send mail and open another port ... 652 maybe. But this in a "while (true)" loop until we run out of ports.
That's being a bit disingenuous. The discussion here hasn't been to open up port 587 to relay for all comers, but rather to open it up for authenticated use only. If spammers start using it, then it's a result of either poor authentication security or an understaffed abuse department. I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection? Andrew
andrew2@one.net wrote:
owner-nanog@merit.edu wrote:
On Thu, Feb 24, 2005 at 04:02:20PM -0700, Smoot Carl-Mitchell wrote:
On Thu, 2005-02-24 at 17:14 -0500, Jim Popovitch wrote:
If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave
the rest alone?
I did run into a case where supporting port 587 was useful. I found out the hard way that one Internet service provider for hotels blocked outbound port 25, but not 587. So sending outbound mail to my mail relay would have been impossible without support for port 587.
It's so funny. On this list many argued Port 25 outgoing must be blocked only to notice, that users actually seem to need it to send mail. Now we must configure our mailservers to listen on 587 to circumvent these filters, that were stupid in the first place.
Now to my prophecy mode: Spammers will start using 587 to spam, which we then also all block outgoing, notice again that customers still want to send mail and open another port ... 652 maybe. But this in a "while (true)" loop until we run out of ports.
That's being a bit disingenuous. The discussion here hasn't been to open up port 587 to relay for all comers, but rather to open it up for authenticated use only. If spammers start using it, then it's a result of either poor authentication security or an understaffed abuse department. I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
Andrew
In this while loop the break is that when authenticated customers abuse the authenticated service they will be terminated, not the service. I do not see a repeat step here. Oh you mean un-authenticated direct-to-mx spammable 587? Yes please, keep that turned off. We need 587 because trusted authentication in SMTP does not transit with the message. So there is no way to require authenticated email only from all systems that would be worth a damn. Therefore, the goal is to corall the message submitting users onto authentication required gateways into the smtp network and reserve the ability to only allow port 25 to known servers.
Joe Maimon wrote:
We need 587 because trusted authentication in SMTP does not transit with the message. So there is no way to require authenticated email only from all systems that would be worth a damn.
Local delivery only unless authenticated isn't worth a damn? Is this really that difficult?? Andrew
owner-nanog@merit.edu wrote:
Joe Maimon wrote:
We need 587 because trusted authentication in SMTP does not transit with the message. So there is no way to require authenticated email only from all systems that would be worth a damn.
Local delivery only unless authenticated isn't worth a damn? Is this really that difficult??
Andrew
Sorry, I misread that. But I still fail to see how 587 changes that. Trojans, viruses, etc. etc. etc. can still exploit the authentication system regardless of what port it operates on. Different port, same old problems. Andrew
On Fri, 25 Feb 2005 12:56:50 EST, andrew2@one.net said:
Sorry, I misread that. But I still fail to see how 587 changes that. Trojans, viruses, etc. etc. etc. can still exploit the authentication system regardless of what port it operates on. Different port, same old problems.
It changes it only in that it becomes a *lot* easier for you to track down which of your users has a compromised machine. (It's a lot easier to just look at the Received: headers than have to take the hostname, chase it back through your logs, and all that - especially if the user is roaming and just caught something over their Aunt Tilly's unsecured wireless access point....)
Valdis.Kletnieks@vt.edu wrote:
On Fri, 25 Feb 2005 12:56:50 EST, andrew2@one.net said:
Sorry, I misread that. But I still fail to see how 587 changes that. Trojans, viruses, etc. etc. etc. can still exploit the authentication system regardless of what port it operates on. Different port, same old problems.
It changes it only in that it becomes a *lot* easier for you to track down which of your users has a compromised machine. (It's a lot easier to just look at the Received: headers than have to take the hostname, chase it back through your logs, and all that - especially if the user is roaming and just caught something over their Aunt Tilly's unsecured wireless access point....)
Yes. Authenticated SMTP makes tracking down which of your users is doing the spamming easier. But you're assuming that SMTP AUTH isn't being used on port 25 already. You can do SMTP AUTH just as easily on port 25 without having to re-educate your users and still net the same simplified tracking procedures that you mention. It sounds to me like what we should really be talking about is getting MTA operators to begin using SMTP authentication of some kind (any kind!), rather than harping on whether or not MTA's should accept mail on port 587... Andrew
On Fri, 25 Feb 2005 andrew2@one.net wrote:
being used on port 25 already. You can do SMTP AUTH just as easily on port 25 without having to re-educate your users and still net the same simplified tracking procedures that you mention. It sounds to me like what we should really be talking about is getting MTA operators to begin using SMTP authentication of some kind (any kind!), rather than harping on whether or not MTA's should accept mail on port 587...
Port 587 becomes useful because it allows you to firewall outbound port 25 from non-mail servers (IE -users), while allowing them to submit mail to other places. It's hard to say how it benefits YOU as a single person. But the separation benefits the Internet as a whole. It's a two part thing though. Blocking port 25 won't work without and alternative for users, and having mail submitted to relays on 587 isn't helpful if local admins don't block port 25 outbound for their users. However, with both of these in place, you stop the ability of every virus-infected host to send mail out directly to other people's mail servers. Forcing them through your mail relay gives you control: Your virus scanner can now detect the traffic, issue an alert, shut down the account, etc. So to answer Nil's original question, along the lines of giving him a reason to listen on port 587, the only selfish reason would be so your users behind port 25 firewalls can relay through your server. If you don't need that, that don't bother. Simply making this available has caused us really no additional support requests, it's maybe two lines in the sendmail.mc file. On the other hand, Optimum Online deciding to block outbound port 25 one (Saturday) morning caused quite a bit of support work. Had we not already been supporting 587 at that point, the work would have been far greater, if not for the techs, then for the salespeople trying to get new customers to replace all the ones we would have lost. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
[Note reply-to] On Fri, Feb 25, 2005 at 02:45:40PM -0500, andrew2@one.net wrote:
Valdis.Kletnieks@vt.edu wrote:
On Fri, 25 Feb 2005 12:56:50 EST, andrew2@one.net said:
Sorry, I misread that. But I still fail to see how 587 changes that. [snip] Yes. Authenticated SMTP makes tracking down which of your users is doing the spamming easier. But you're assuming that SMTP AUTH isn't being used on port 25 already. You can do SMTP AUTH just as easily on [snip]
You do not authenticate every transaction on 25, else you wouldn't be getting any smtp from the real world. The point is that you can trivially sort "must be authenticated" vs "is unknown" as opposed to inspecting messages on "dunno if might be anything" port. Reducing the problem space is always a Good Thing. The real funny thing is that o started to write back to the earlier incarnation of this thread. Pasted below because it still applies. I'd rephrase Sean's question as 'why do so few SMALL mail providers [...]'. Bluntly, if AOL/etc can do it with their customer base then the 'bad' laziness is the only reason not to do so, or to rgue against those who wish to do so. On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote: [snip] Seans rhetorical subject line was answered quite adequately by the rampant ignorance in the knee-jerk responses of those who have obviously not read the RFC in its many years of availability, thought about the consequences, nor been down the road of implementation. Rather than armchair nattering, come to the discussion prepared or sit on the sidelines and observe. If you haven't done your homework, you are Not Tall Enough To Ride This Ride and go to the queue for the spinning teacups. The beauty of what we've all been building for all these years is it is all documented; given a brain and desire you can go from clueless to clueful purely through self-educating. If you are expecting to be spood-fed then please return to the flow charts and MOPs of vendor certifications. Questions regarding the spec, document, implementations thereof are useful and have popped up, but in general there's a really sad trend of uninformed chattering. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Fri, 25 Feb 2005 andrew2@one.net wrote:
Sorry, I misread that. But I still fail to see how 587 changes that. Trojans, viruses, etc. etc. etc. can still exploit the authentication system regardless of what port it operates on. Different port, same old problems.
Sigh, if even the network professionals have difficulty understanding how things work, what hope is there for the rest of the users. Requiring end-user systems to use only authentication port 587 to send outbound mail means even if they are infected with trojans, viruses, etc, they will only be able to send mail via the (few) mail servers on which they have an authenticated account. Hopefully, then the local mail administrator could run server-based anti-virus/anti-spam checks on the outgoing e-mail from authenticated local users (including those users which may have had their anti-virus/anti-spam software compromised on the PC) before forwarding it to other mail servers on the Internet. When end-users systems have direct access to port 25 on all Internet mail servers, an end-user system infected with a trojan, viruses, etc will send mail to other mail servers on the Internet directly without needing to authenticate itself because mail servers still need to accept unauthenticated mail from anywhere for local delivery on Port 25. Waiting for complaints, installing network sniffers (assuming you can find a sniffer big enough) or conducting intrusive scans of the user's computers tends to be re-active rather than pro-active; and can result in a trojan or virus sending large quantities of mail directly from the infected computer. Of course, it would be great news and a good goal if end-user computers were never compromised and their anti-virus definitions were always up to date, and so on. But that is a bit unrealistic for unmanaged end-user systems. Requiring end-user computers to use authenticated Port 587 and blocking end-user computers access to port 25 has several advantages: 1. Reduces the number of mail servers to which an infected end-user computer has direct access without authentication. They still have indirect access if their authenticated mail server forwards it without further checks. 2. Lets the authenticated mail server conduct additional anti-virus checks on outgoing mail even if the end-user's computer was compromised or out-of-date virus definitions. 3. Separates authenticate mail submission (port 587) from other mail protocols (25, 110, 143, etc) simplfying network controls (no deep-packet inspection) for end-user computers. Eliminates some of the existing problems with trying to do transparent proxying of port 25 from end-user computers. 4. Allows the source network to make exceptions for individual addresses instead of trying to modify DUL RBL's used by destination mail servers if an end-user runs their own mail server. 5. Lets a roaming end-user computer use the same mail configuration when it is on its "home" network or on a "remote" network to access its primary authenticated mail server instead of needing to change to a different local network mail server. If all your users always use a VPN, this may be less important. But if none of those change you mind, nothing can force you to offer Port 587 authenticated mail submmission, VPN or web mail access for your users. If you choose not too, that is between you and your users. There is a good chance your users will experience problems when traveling or roaming unless you offer some of those alternatives.
SD> Date: Sat, 26 Feb 2005 00:24:16 -0500 (EST) SD> From: Sean Donelan SD> Sigh, if even the network professionals have difficulty understanding SD> how things work, what hope is there for the rest of the users. Funny you should say that. I frequently comment that the average "service provider" of today is less competent and more apathetic than the average end user of a decade ago. I'd absolutely _love_ to be proven wrong. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
In message <Pine.GSO.4.58.0502252320550.6102@clifden.donelan.com>, Sean Donelan writes:
Requiring end-user computers to use authenticated Port 587 and blocking end-user computers access to port 25 has several advantages:
2. Lets the authenticated mail server conduct additional anti-virus checks on outgoing mail even if the end-user's computer was compromised or out-of-date virus definitions. 3. Separates authenticate mail submission (port 587) from other mail protocols (25, 110, 143, etc) simplfying network controls (no deep-packet inspection) for end-user computers. Eliminates some of the existing problems with trying to do transparent proxying of port 25 from end-user computers.
What these two boil down it is a much simpler mail system architecture, which in turn translates to a more secure mail system and an easier-to-administer one. Consider the control flow if you're trying to use port 25 for everything: Send a 220 If you see an EHLO, advertise that you support STARTTLS If you receive a STARTTLS and another EHLO, advertise that you support AUTH -- you don't want to do authentication over insecure connections, especially if your goal is to support roaming wireless users. Accept inbound email. Check if the user was authenticated. If so, permit relaying; also do rate checks. If not, don't permit relaying, but do run anti-spam software. Do virus checks. If authenticated, notify the sender that either their machine is infested with *something* or their credentials have been stolen. If unauthenticated, discard; it's probably a joe job. The point is that authenticated status has to be retained and checked frequently. If you're using 587, the subscriber flow is like this: Send a 220 Don't accept anything until you see STARTTLS Don't do anything until you see an AUTH Accept inbound mail, do rate checks and virus checks, and bounce accordingly For port 25: Send a 220 Optionally permit (but don't require) STARTTLS Accept inbound mail. Do virus and spam checks, and drop as needed. Don't permit relaying Both are simpler; neither requires retained global state.
On Fri, 25 Feb 2005 11:17:35 -0500, andrew2@one.net <andrew2@one.net> wrote:
That's being a bit disingenuous. The discussion here hasn't been to open up port 587 to relay for all comers, but rather to open it up for authenticated use only. If spammers start using it, then it's a result of either poor authentication security or an understaffed abuse department. I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
Port 587 is intended for authenticated mail relaying only. While you can set up authenticated relaying only on port 25, you still have to deal with spammers sending mail directly to your users on port 25. Blocking port 25 outbound from dynamic ips (dialups, dsl, cable, etc) helps a little bit .. But then you need an alternate port for relaying. I think using port 587 for authorized relaying and port 25 for normal smtp services works out well. I can't think of a valid reason to ever block port 587, and I can't see how spammers will use port 587 for spamming, unless they have a username/password for relaying..
Andrew
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com
I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone. Unfortunately, providers seem to prefer unilateral heavy-handed behavior rather than acting professional. They prefer working out solutions in isolation or in small closed cabals working in secret in backrooms rather than working open to public scrutiny in an association. They prefer to operate in an environment in which there are no agreed policies for Internet email exchange rather than having a viable Internet email system in which everyone works together to add value to the users. They prefer to play secret games with blacklists, bayesian filters, hodge-podges tacked onto the Internet's DNS systems, and other antisocial behaviors rather than openly saying that people must meet certain standards in order to *SEND* email. The Internet email architecture is based on something called *SIMPLE* mail transport protocol which its creator never intended to last for so long. It is a flat architecture and in common with other flat architectures it does not scale. If flat architectures did scale on the Internet, then everyone with a dialup would be running BGP and announcing their /32 IPv4 route. There is no good reason why the large email providers, most of whom are network operators, do not form an open Internet Mail Services Association to hammer out the details of a new email services architecture so that everyone can sing from the same hymnbook and so that email just works, seamlessly, everywhere. I strongly suspect that a new architecture will have fewer weak points that can be exploited by spammers but spam is really a secondary problem. The real problem is that the IETF protocol development process is not the right place for email service operators to work out operational frameworks and policies. This is an area where the United Nations and the ITU can bring about *REAL* improvements to the Internet and I hope that the existence of the WSIS will lead to this. No, I do *NOT* support the ITU taking on a governance role over the Internet. What I do support is for the companies in this industry to wake up and smell the coffee. Nature abhors a vacuum. Currently we have collectively created a vacuum which the UN and ITU *WILL* fill if we don't fill it first. --Michael Dillon
On Fri, 25 Feb 2005 16:51:31 +0000, Michael.Dillon@radianz.com <Michael.Dillon@radianz.com> wrote:
I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone.
You might want to check out http://www.maawg.org - at least stateside, that's about the only operational mail admin / antispam conference I know of that's attended by ISP mail system and abuse desk admins rather than assorted vendors. They've got a mtg march 1-3 in San Diego (I'll be there btw) srs
Unfortunately, providers seem to prefer unilateral heavy-handed behavior rather than acting professional. They prefer working out solutions in isolation or in small closed cabals working in secret in backrooms rather than working open to public scrutiny in an association. They prefer to operate in an environment in which there are no agreed policies for Internet email exchange rather than having a viable Internet email system in which everyone works together to add value to the users. They prefer to play secret games with blacklists, bayesian filters, hodge-podges tacked onto the Internet's DNS systems, and other antisocial behaviors rather than openly saying that people must meet certain standards in order to *SEND* email.
The Internet email architecture is based on something called *SIMPLE* mail transport protocol which its creator never intended to last for so long. It is a flat architecture and in common with other flat architectures it does not scale. If flat architectures did scale on the Internet, then everyone with a dialup would be running BGP and announcing their /32 IPv4 route.
There is no good reason why the large email providers, most of whom are network operators, do not form an open Internet Mail Services Association to hammer out the details of a new email services architecture so that everyone can sing from the same hymnbook and so that email just works, seamlessly, everywhere. I strongly suspect that a new architecture will have fewer weak points that can be exploited by spammers but spam is really a secondary problem. The real problem is that the IETF protocol development process is not the right place for email service operators to work out operational frameworks and policies.
This is an area where the United Nations and the ITU can bring about *REAL* improvements to the Internet and I hope that the existence of the WSIS will lead to this. No, I do *NOT* support the ITU taking on a governance role over the Internet. What I do support is for the companies in this industry to wake up and smell the coffee. Nature abhors a vacuum. Currently we have collectively created a vacuum which the UN and ITU *WILL* fill if we don't fill it first.
--Michael Dillon
-- Suresh Ramasubramanian (ops.lists@gmail.com)
You might want to check out http://www.maawg.org - at least stateside,
I'm uncomfortable with two aspects of this group. First is it's anti-abuse stance. I would prefer to see a group that was focussed on services, i.e. providing the best email service possible to end-users. The second thing is the secrecy surrounding this group. It seems that they see themselves as some sort of private police force and I believe that is 180 degrees in the opposite direction from where we should be going. If there is too much crime in the streets, should we have citizen militias out there carrying guns? This seems to be the approach that MAAWG is taking. Quite frankly, there is too much emotion involved in the email issue. Too many people who irrationally hate spam and are willing to take extreme measures as a result. I do not believe that there is a spam problem at all. We merely have a creaky old email architecture built tacked together out of sticks and glue. From a distance, it looks impressive, but it suffers from many weaknesses which vandals, and now criminals, can exploit. I know that if we fix the internet email services architecture, then the bad guys will just miraculously disappear. It's like tearing down a drafty, leaky old building and putting up an airtight, insulated building on the same site. I once knew a guy who built a massive greenhouse out of 1" by 2" strips of scrap would from a sawmill. It was sticker wood for those from the Northwest. You could only get maybe 3 feet of useful length before there was a knot or it was warped too badly. He nailed these together to make 2 x 6 's and bigger beams. He build walls, 4 feet high all around, 40 feet wide and 200 feet long. Then he pieced together arches to hold the polyethylene sheeting. Inside he built raised beds of wood and two stories of lattice shelving above them. The beds were 3 feet wide arranged in aisled on either side of a central aisle. He did all this with a saw, thousands of nails, and these thin strips of wood. It worked for a few months, and grew some great early strawberries. He had it filled with tomato and melon vines just beginning to bloom when it started to tilt. Fact is, this structure had too many weaknesses. Insect pests crawled in through the cracks. Warm air escaped through the cracks. Moisture condensed in the cracks causing mold and rot to begin, and the wood to swell and warp in interesting ways. There were too many weaknesses, too many points at which it could be attacked by the elements. So, only 5 months after he began to build it in early March, I helped him set fire to the dangerous structure on a rainy July morning. It was the safest and cheapest way to dismantle the building which, let's face it, had no scrap value. The local fire department agreed that it was best done before the summer heat parched the landscape. And that was that. The Internet's current email architecture isn't quite as bad as the greenhouse. There are many bits that can be salvaged, but the salvage work requires coordinated effort and I do not see any organization in the world that is capable of stepping up to such a challenge outside of the ITU and the various national governments. Either we create an organization dedicated to providing a superior email service to end users, or we will all be implementing ITU email standards to comply with new legislation. --Michael Dillon
On 02/25/05, Michael.Dillon@radianz.com wrote:
You might want to check out http://www.maawg.org - at least stateside,
I'm uncomfortable with two aspects of this group. First is it's anti-abuse stance. I would prefer to see a group that was focussed on services, i.e. providing the best email service possible to end-users.
Services are the competitive differentiator between the various companies which do e-mail, so that's not likely to happen.
The second thing is the secrecy surrounding this group.
You (or anyone else) can attend the meeting in San Diego. The price online for non-members was $100, but online registration is closed and I don't know what it'll cost on-site. Here's the agenda, complete with topics and names of presenters and who they each work for: http://www.maawg.org/news/news/0503_GeneralMeeting The secret has been revealed! Viva la revolucion! -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
And what's an even stranger secret is that MAAWG members get to pay double the registration fee of non maawg members :) Now that's openness for you ... Come on in .. it is the nearest thing to nanog that I've seen for mail ops people in the NA region (+ quite a lot of the world). --srs (I like apcauce better, but well I organize it so I got to be proud of it) :) On Fri, 25 Feb 2005 16:47:31 -0800, J.D. Falk <jdfalk@cybernothing.org> wrote:
The second thing is the secrecy surrounding this group.
You (or anyone else) can attend the meeting in San Diego. The price online for non-members was $100, but online registration is closed and I don't know what it'll cost on-site. Here's the agenda, complete with topics and names of presenters and who they each work for:
http://www.maawg.org/news/news/0503_GeneralMeeting
The secret has been revealed! Viva la revolucion!
-- Suresh Ramasubramanian (ops.lists@gmail.com)
* Michael.Dillon@radianz.com (Michael.Dillon@radianz.com) [Fri 25 Feb 2005, 18:13 CET]:
Unfortunately, providers seem to prefer unilateral heavy-handed behavior rather than acting professional. They prefer working out solutions in isolation or in small closed cabals working in secret in backrooms rather than working open to public scrutiny in an association. They prefer to operate in an environment in which there are no agreed policies for Internet email exchange rather than having a viable Internet email system in which everyone works together to add value to the users. They prefer to play secret games with blacklists, bayesian filters, hodge-podges tacked onto the Internet's DNS systems, and other antisocial behaviors rather than openly saying that people must meet certain standards in order to *SEND* email.
You keep riding this particular horse. Right now, to connect to the Internet you need to comply with quite some regulations already - have a computer and a modem and a contract with a dialup ISP, or even get DSL or cable installed. More options are available if you have more money, companies can pay for redundant T3's etc. Obviously this has not kept the `bad guys' out. Why do you think that enforcing contractual relationships for e-mail as well as basic IP service will make any difference? Why do you believe more red tape will mean better service? -- Niels. -- The idle mind is the devil's playground
Unfortunately, providers seem to prefer unilateral heavy-handed behavior rather than acting professional. They prefer working out solutions in isolation or in small closed cabals working in secret in backrooms rather than working open to public scrutiny in an association. They prefer to operate in an environment in which there are no agreed policies for Internet email exchange rather than having a viable Internet email system in which everyone works together to add value to the users. They prefer to play secret games with blacklists, bayesian filters, hodge-podges tacked onto the Internet's DNS systems, and other antisocial behaviors rather than openly saying that people must meet certain standards in order to *SEND* email.
Why do you believe more red tape will mean better service?
You misunderstand me. I believe *LESS* red tape will mean better service. Today, an email operator has to deal with numerous blacklisting and spam-hunting groups, many of which act in secret and none of which have any accountability, either to email operators, email users or the public. I'd like to see all of this inscrutable red tape swept aside with a single open and public organization that I have been calling the Internet Mail Services Association. This will mean less red tape, more transparency, and more accountability. --Michael Dillon
On Mon, 28 Feb 2005 10:35:53 GMT, Michael.Dillon@radianz.com said:
You misunderstand me. I believe *LESS* red tape will mean better service. Today, an email operator has to deal with numerous blacklisting and spam-hunting groups, many of which act in secret and none of which have any accountability, either to email operators, email users or the public.
Actually, most of those blacklisting groups have the *ultimate* accountability to e-mail operators - if the operators disagree with the way the group does things, they stop using the blacklist. I'm making the rash assumption that operators are klooed enough to either not use a blacklist they don't agree with, or know how to whitelist their disagreements. If the operator isn't, well.. consider it time for evolution in action.
I'd like to see all of this inscrutable red tape swept aside with a single open and public organization that I have been
And you intend to get enough consensus of goal amongst all these divergent groups with their differing goals and criteria, how, exactly? Remember that we as an industru (at least as represented on NANOG) can't even come to an agreement about port 587 or filtering 1918-sourced addresses. ;)
[ This discussion should be moved to Spam-L. ] On Mon, Feb 28, 2005 at 10:35:53AM +0000, Michael.Dillon@radianz.com wrote:
You misunderstand me. I believe *LESS* red tape will mean better service. Today, an email operator has to deal with numerous blacklisting and spam-hunting groups, many of which act in secret and none of which have any accountability, either to email operators, email users or the public.
Nonsense. Those groups are accountable to those who choose to avail themselves of their work. Mail system operators -- as they have already demonstrated by their actions -- will not use those resources which are run incompetently or which do not provide satisfactory results. And the wide range of resources available (there are probably about 500 DNSBLs at the moment) and the variety of policies by which they're run provides healthy competition as well as a selection of tools sufficient to allow just about any local policy to be implemented. There is no need for these operators of these resources (say, SPEWS) to be accountable to anyone else. Why should they be? They merely publish a list. If you don't like their list or the policies they use to build it: don't use it. But know that everyone else will make their choices according to their own needs, not yours.
I'd like to see all of this inscrutable red tape swept aside with a single open and public organization that I have been calling the Internet Mail Services Association. This will mean less red tape, more transparency, and more accountability.
It will also mean that anyone with deep enough pockets to buy their way in will get a pass to spam as much as they want. Sorry, but this experiment has already been run (see "bonded spammer") and has been a miserable failure. Besides, there is no "inscrutable red tape". Dealing with DNSBLs is quite easy. Of course, you may not get the results *you* wish to have, but if you're running or occupying a spammer-infested network, then the results *you* wish to have are unimportant. ---Rsk
On Fri, 25 Feb 2005 Michael.Dillon@radianz.com wrote:
I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
Because that would require providers to act like professionals
I don't see what the big deal is. mx.justthe.net, for instance, requires SMTP AUTH on port 587 for everyone and requires SMTP AUTH on port 25 for anyone attempting to relay mail outside my network. The biggest cost I can see, and it *is* a significant cost, is walking users through the process of configuring their MUAs to do the authentication. Configuring the servers, however, shouldn't be a huge problem, and you can mitigate the cost issue by only setting up 587 for people who need to have it set up. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "In case anyone was wondering, that big glowing globe above the Victor Valley is the sun." -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)
At 4:51 PM +0000 2/25/05, Michael.Dillon@radianz.com wrote:
I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone.
Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone. The problem isn't agreements, the problem is that there are borders at which people will not be willing to block, even if there is bad behavior. After all, there's nothing stopping ISPs from blocking port 25 passing through their networks now. But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry. If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?). That kind of thing needs government level action. It's highly unlikely to happen, and it's far from clear that we would want it to. -- Kee Hinckley http://www.messagegate.com/ Enterprise Messaging Security and Compliance http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
On Mon, 2005-02-28 at 11:44 -0600, Kee Hinckley wrote:
At 4:51 PM +0000 2/25/05, Michael.Dillon@radianz.com wrote:
Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone.
Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone. The problem isn't agreements, the problem is that there are borders at which people will not be willing to block, even if there is bad behavior.
Access providers ensuring machines from dynamic addresses are excluded from sinking or sourcing port 25 traffic would prevent residential customer's machines from acting as an anonymous SMTP client, with an exception often made between their own servers. Blocking port 25 traffic in both directions prevents address spoofing (done by tunneling reply traffic to an unblocked node elsewhere). This leaves the provider in control of their address space, as this space should not become blocked due to a history of abuse, largely due to customer's compromised systems. As an additional benefit, their networks should be less burdened on the up-link, and their customers less exposed to viruses, should blocking be done at the access interface, rather than upstream at more expensive routers.
After all, there's nothing stopping ISPs from blocking port 25 passing through their networks now.
Until alternative authenticated SMTP ports become prevalently used, there is potential for support issues, once a portion of their customers are unable to use their laptops at different locations. A solution is provided with alternative authenticated access ports, in conjunction with port 25 blocking, but this still involves a configuration change. The trade-off is less abuse reports, assuming this is monitored.
But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry.
Mapping dynamic addresses can be problematic from regions that do not cooperate, even when it is in their best interests to do so. A great deal of abuse is prevented using the black-hole listing methods, where, without this mechanism, email would not be practical. Capricious listings would be an expensive alternative for any listing service, however.
If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?). That kind of thing needs government level action. It's highly unlikely to happen, and it's far from clear that we would want it to.
There should be similar concerns regarding demands for DNS entries to register paths of a mailbox-domain before email is accepted. This approach attempts to burden the mailbox-domain owner, rather than the email service provider, with responding to abuse. Users of email services, however, often have no means to monitor abuse of these address based authorizations, which may result in their mailbox-domain becoming unusable. Attempting to track the source of a problem may become impossible should listing services refuse to provide sources, or providers refuse to share logs due to privacy issues. There is no standardization for path registration schemes, such as Sender-ID/SPF/SPF-Classic(new version of SPF). Although these three different schemes claim to use the same DNS record, they apply far different rules for various mailbox-domains. Asking for logs as to why mail has gone missing may require learning about everyone's use of RFC2822 FROM, or SENDER, or RESENT-FROM, or RESENT-SENDER, or RFC2821 MAILFROM depending upon which email filtering algorithm was applied. There is no means to discern which mailbox-domain within messages were subjected to filtering or reputation assessments. This says nothing of risks imposed by active content in DNS, the ignoring of exponential UDP back-off, and requiring compliant receivers to parse more than 100 DNS records, etc. -Doug
Because that would require providers to act like professionals, join an Internet Mail Services Association, agree on policies for mail exchange, and require mail peering agreements in order to enable port 25 access to anyone.
Nice in theory, but I don't think it would scale. In essence you are asking for a return to the UUCP model, where if you wanted to send mail on the network you had to have a deal with someone.
No, I am not suggesting a return to the UUCP model. If I was then I would have said that. I am suggesting that we apply the lessons learned from the BGP peering model. The BGP peering model evolved over many years of people hashing out and modifying many bilateral peering agreements. I don't think we need to do this with email, because we the larger email providers can all sit down and together and based on the BGP experience, they can come up with a standard multilateral agreement that will suit most people. Or, more likely, two multilateral agreements. One for members of the email peering core, and the other for non-core operators. The reason this needs to be done in an association, in public, is because email is not BGP. BGP is an arcane piece of technology which does an arcane job in interconnecting networks. There is no significant public interest in BGP. Email, on the other hand, is an end user service and it is abundantly clear that the end users of the world are FED UP with the inability of Internet email providers to maintain and improve the quality of the service. Every year for the past 10 years the quality of Internet email has degraded. And while other services like instant messaging can take up some of the slack, they cannot fully replace a store and foreward email system.
But, every time someone tries a blanket block of (for instance) China, or even appears to do so, there's a huge outcry. If you create an organization to do that, you'll not only have an outcry, you'll have a target for legal action (restraint of trade?).
There you go again, just like everyone else. You assume that the problem is somebody else and we just need to shoot that somebody else with big guns. Well, I have news for you. I HAVE SEEN THE ENEMY AND HE IS US! The problem is a fundamental shoddiness in the email services architecture which is compounded by a fundamental shoddiness in email service operations. Bandaid solutions abound. The whole thing is made out of bits of string and sealing wax. I recommend that you read Dave Crocker's draft on Internet email architecture. http://www.bbiw.net/specifications/draft-crocker-email-arch-03.html In order to understand what I am getting at you have to begin looking at the problem from a high level, not down in the greasy gearboxes. Dave's draft can be a bit inscrutable, but he is at least trying to document the overall architecture so that we can talk clearly about how to manage it in a way that provides a high quality email service to the end user. --Michael Dillon
No, I am not suggesting a return to the UUCP model. If I was then I would have said that. I am suggesting that we apply the lessons learned from the BGP peering model.
I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers.
On Tue, Mar 01, 2005 at 05:44:26AM -0500, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote a message of 27 lines which said:
I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers.
The agenda of the people who praise "email peering" is probably to change that. "Should anyone be allowed to operate an email system? Perhaps not." AOL postmaster Carl Hutzler http://www.circleid.com/article/917_0_1_0_C/
On Tue, 1 Mar 2005 12:01:35 +0100, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
The agenda of the people who praise "email peering" is probably to change that.
"Should anyone be allowed to operate an email system? Perhaps not."
AOL postmaster Carl Hutzler
Where does that advocate email peering? As long as you have 1. A static IP 2. Reasonable technical competence (clue being such a rare beast) I dont see Carl, or anybody else, objecting Cue rants about how some people shouldnt be allowed to have root, enable or whatever on etch a sketches, let alone production machines. You've seen such people and so have I ... -- Suresh Ramasubramanian (ops.lists@gmail.com)
No, I am not suggesting a return to the UUCP model. If I was then I would have said that. I am suggesting that we apply the lessons learned from the BGP peering model.
I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers.
Well the way that I see this scaling is that you have a core of email service providers who are members of the Internet Mail Services Association. These core operators sign up to a multilateral mail peering agreement and provide email transit services for other operators. The next layer is the non-core email service providers who have bilateral mail peering agreements with one or more core email transport providers. They essentially relay their email through a core provider, or possibly, they use some credential provided by their peer in the core to connect directly to other core members. The key thing here is that there is some kind of contractual agreement between the second tier and the core members. If the second tier breaks the agreement, their email flow is summarily cut off. You can do that with contracts. The mechanism for email transport and authentication is something that other people can work out. I know that relaying will work, but may not scale. However there are ways around this by separating the credentials/authentication from the mail flow. For instance, the 2nd tier provider connects to his peer in the core (CORE A) and asks for a credential to send mail to another core member (CORE B). CORE A hands him a magic cookie. He connects to CORE B and hands over the cookie. CORE B validates that this is a legitimate credential from CORE A. Email flows. And then there is the last layer which I call the end user. Of course this includes many organizations as well as individuals. It could even include someone who hosts mailing lists, i.e. someone who sources large volumes of mail. These people never talk to the core providers and submit all their email to a 2nd tier provider through the authenticated submission port. This group is the most important group because the entire system exists to serve their needs. Note that a large provider like AOL would be both a core email services provider and a 2nd tier provider at the same time. The 2nd tier deals with end users. In fact, AOL will also be an end user as will every other company. It is more useful to think of the functionality here rather than trying to map specific companies into a specific layer. I think that most people will agree that the architecture that I have described stands a good chance of scaling to a global level. And if there are some scaling issues that arise, they should be able to be solved within the core, i.e. the group with multilateral email peering agreements. They may decide to put some hierarchy within the core to match up with geography on a broad scale. --Michael Dillon
Michael.Dillon@radianz.com wrote: | The key thing here is that there is some kind of contractual agreement | between the second tier and the core members. If the second tier breaks | the agreement, their email flow is summarily cut off. You can do that | with contracts. Yup. As you've mentioned, we already have a mechanism for peering between providers - it's called BGP. Is it too much to ask for BGP peering contracts to include requirements to deal with abuse ?
| The key thing here is that there is some kind of contractual agreement | between the second tier and the core members. If the second tier breaks | the agreement, their email flow is summarily cut off. You can do that | with contracts.
Yup.
As you've mentioned, we already have a mechanism for peering between providers - it's called BGP. Is it too much to ask for BGP peering contracts to include requirements to deal with abuse ?
Yes, I think that it is too much to ask for. Abuse has little to no impact on peering beyond minor traffic increments. Why should a BGP peering contract place a lot of importance on this? Certainly, BGP peering contracts do include some mention of abuse contacts and so on, but it is a side issue. However, when you consider email services, it is a different story. Whether it is abuse or whether it is shoddy email operations or whether it is misconfigured email server software, it WILL create major impacts on the quality of the email service. Most of this isn't even noticed by the NOC because they only care that packets flow smoothly. In order to improve the quality of Internet email service, we need more than the smooth flow of packets. We need the right packets in the right place at the right time, and only the right packets. --Michael Dillon
On Tue, 1 Mar 2005 Michael.Dillon@radianz.com wrote:
I'm skeptical that a model that only sort of works for under 30K ASNs and maybe 1K bilateral peering agreements for the *really* big Tier-1s won't scale to a world that has 40M+ .com domains and probably a million SMTP servers.
Well the way that I see this scaling is that you have a core of email service providers who are members of the Internet Mail Services Association.
The business world simply doesn't work that way. Ever heard of the phrase "Standards are great -- there's so many of them to choose from!"?
These core operators sign up to a multilateral mail peering agreement and provide email transit services for other operators.
The next layer is the non-core email service providers who have bilateral mail peering agreements with one or more core email transport providers.
Contrary to what you said before, this *IS* the UUCP model in a nutshell. It has been done before, it does not scale, and it does not fit the way business works today. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
* tv@duh.org (Todd Vierling) [Tue 01 Mar 2005, 19:18 CET]:
On Tue, 1 Mar 2005 Michael.Dillon@radianz.com wrote: [..]
These core operators sign up to a multilateral mail peering agreement and provide email transit services for other operators.
The next layer is the non-core email service providers who have bilateral mail peering agreements with one or more core email transport providers.
Contrary to what you said before, this *IS* the UUCP model in a nutshell. It has been done before, it does not scale, and it does not fit the way business works today.
It looks more like the way the GPRS roaming world has been set up by a few telcos. I don't think that's how you necessarily want to shape your e-mail roaming agreements, let alone *all* e-mail exchanges. -- Niels. -- The idle mind is the devil's playground
On Tue, 1 Mar 2005 10:30:21 +0000, Michael.Dillon@radianz.com wrote:
� I am suggesting that �we apply the lessons learned from the BGP peering � model.
When a diverse community uses an infrastructure service, it needs some basis for trusting the activity of that service. The nature and degree of trust depends on the nature of the service, of course, but there always are limits to the types and amount of misbehaviors that can be tolerated, beyond which the serviced is rendered useless. The global telecommunications and postal infrastructures have been based on country government authorization and oversight, with a combination of inter-country treaties and inter-provider contracts specifying formal requirements. The modern Internet uses an entirely different trust model, since most service providers operate strictly through market forces, rather than having any government oversight. Anyone can play. So we have no reliable way to assess trust of the overall service, because it has no separate identity. That means assessing each service participant individually. That's a textbook example of a scheme that does not scale. What is missing, then, are two things: 1. Specification of acceptable practises, so there can be a shared view of "good email provider"; and 2. A processes which assesses performance according to those practises. Both of these require a community to form, develop the specification, and assess conformance to its requirements. There are informal examples of such communities already operating. The challenge is to develop something that scales. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker �a t ... WE'VE MOVED to: �www.bbiw.net
On 2/25/2005 11:17 AM, andrew2@one.net wrote:
department. I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection?
It's not just authentication. Mail from local users might need some fix-up work done to it, like adding Date or Message-ID, or completing a mail-domain in an address, or doing some other kind of cleanup. You don't necesarily want to do that for server-server messages, since their absence is good spam-sign, but at the same time you do want to do it for user mail. You can also conduct different kinds of tests, perform different kinds of rate-limiting, map in different headers (auth, for example), and so forth. Separating your traffic is good management. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Fri, Feb 25, 2005 at 10:47:59AM -0500, Nils Ketelsen wrote:
Now to my prophecy mode: Spammers will start using 587 to spam, which we then also all block outgoing, notice again that customers still want to
The trick is to config port 587 in such a way that it ONLY accepts smtp-auth mail, not regular smtp. That way, virii/spam junk won't be able to use that port. Kind Regards, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
On Fri, 25 Feb 2005, Frank Louwers wrote: The trick is to config port 587 in such a way that it ONLY accepts smtp-auth mail, not regular smtp. That way, virii/spam junk won't be able to use that port. What are you, stupid? The spammers have drone armies of machines with completely compromised operating systems. What makes you think that their mail credentials will be hard to obtain? matt ghali --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
On Fri, 25 Feb 2005, just me wrote:
What are you, stupid? The spammers have drone armies of machines with completely compromised operating systems. What makes you think that their mail credentials will be hard to obtain?
What are you, stupid ? Run a virus scanner on your mail relay so you don't propogate any viruses. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Fri, 25 Feb 2005, Christopher X. Candreva wrote: On Fri, 25 Feb 2005, just me wrote:
What are you, stupid? The spammers have drone armies of machines with completely compromised operating systems. What makes you think that their mail credentials will be hard to obtain?
What are you, stupid ? Run a virus scanner on your mail relay so you don't propogate any viruses. That certainly solves the problem in question, preventing compromised hosts from using their user's credentials to transmit AUTHed spam through their configured smarthost. No, wait, your comment is a total non sequitur. While AUTHed spam from zombies will be easier to detect and block, it is not the Magic Solution that many folks on this list are presenting it as. Most ISPs don't watch logs for the signs of abuse now, why would they magically change their behavior and monitor logs if they required auth? Just because there is more of an audit trail doesn't mean that it will be used. matt ghali --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
On Fri, 25 Feb 2005, just me wrote:
Most ISPs don't watch logs for the signs of abuse now, why would they magically change their behavior and monitor logs if they required auth? Just because there is more of an audit trail doesn't mean that it will be used.
Because now the server sending viruses is their outgoing mail server, which will get blocked via the various DNSBL's instead of the end-user machine, which should be much more of an incentive t clean things up. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
jm> Date: Fri, 25 Feb 2005 14:25:48 -0800 (PST) jm> From: just me jm> What are you, stupid? The spammers have drone armies of machines jm> with completely compromised operating systems. What makes you think jm> that their mail credentials will be hard to obtain? Internal users: With AUTH - correlate message with authenticated user, then forbid mail transmission for them only. I'd rather do that than slog through RADIUS logs. But, hey, maybe if I had more free time... External users: They must send mail somehow. If saying "You roam? Use this port!" is too difficult, try explaining multiple profiles. Short of using 25/TCP on the service provider's network (which could be amusing for those using wholesale dialup providers), users need some way to pass email. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On Fri, 25 Feb 2005, Edward B. Dreger wrote: Internal users: With AUTH - correlate message with authenticated user, then forbid mail transmission for them only. I'd rather do that than slog through RADIUS logs. But, hey, maybe if I had more free time... Increasing the detail of an audit trail doesnt mean anyone will automatically use the information in an effective manner. Without auth, most ISPs could correlate abuse behavior between MTA logs and RADIUS logs, if they cared. Most don't. SMTP AUTH won't change that. matt ghali --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
On 02/25/05, just me <matt@snark.net> wrote:
On Fri, 25 Feb 2005, Edward B. Dreger wrote:
Internal users: With AUTH - correlate message with authenticated user, then forbid mail transmission for them only. I'd rather do that than slog through RADIUS logs. But, hey, maybe if I had more free time...
Increasing the detail of an audit trail doesnt mean anyone will automatically use the information in an effective manner.
Without auth, most ISPs could correlate abuse behavior between MTA logs and RADIUS logs, if they cared. Most don't. SMTP AUTH won't change that.
I don't get it, Matt. Are you trying to tell us that because some ISP's don't care, the ISP's who /do/ care /shouldn't/ move their users to doing mail submissions on port 587? -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
On Fri, 25 Feb 2005, J.D. Falk wrote: On 02/25/05, just me <matt@snark.net> wrote:
Increasing the detail of an audit trail doesnt mean anyone will automatically use the information in an effective manner.
Without auth, most ISPs could correlate abuse behavior between MTA logs and RADIUS logs, if they cared. Most don't. SMTP AUTH won't change that.
I don't get it, Matt. Are you trying to tell us that because some ISP's don't care, the ISP's who /do/ care /shouldn't/ move their users to doing mail submissions on port 587? Of course not- and I eat my own dog food. Come March 1, I will be flipping the switch on a large number of mail policy reforms where I work, including mandatory SMTP AUTH for all campus users. It took a lot of pushing for me to get the policy in place. I believe that in the right environment (including one that I run) the additional control and accounting will be a positive tool. What I disagree with is the constant disingenuous suggestion made here that AUTH by itself has any impact on unwanted email. When the lights are on, but nobody is home, it doesnt matter how detailed the accounting is. And it seems that theres plenty of large providers around the world where this is the case. matt ghali --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
On Fri, 25 Feb 2005, just me wrote:
What I disagree with is the constant disingenuous suggestion made here that AUTH by itself has any impact on unwanted email. When the lights are on, but nobody is home, it doesnt matter how detailed the accounting is. And it seems that theres plenty of large providers around the world where this is the case.
While you may be correct in theory, in the real world you don't have to outrun the bear, just the other guy. Although I still believe in an end-to-end Internet, it is hard to argue with real-life experience. Essentially every provider that has implemented port 25 blocks has seen a substantial drop in problems. The numbers are even better when they added the requirement for authenticated mail submission even for local users. These are the same providers, as you say have nobody home, so that variable didn't change. http://www.cox.com/sandiego/highspeedinternet/spamfaq.asp
Since the implementation of the port 25 blocking procedure, Cox has seen significant decreases in the residential Cox High Speed Internet complaint counts for different abuse types impacted by the port 25 blocking. Port scanning complaints decreased by 36%, virus complaints by 41%, spam complaints by 52%, and open proxy by more than 78%.
I'm not a complete idiot. Everyone expects the malware authors to adapt. Some already have. But when they do, you have made some progress in reducing the footprint back to just the mail servers accepting authenticated submissions instead of every end-user system on the Internet. Even at providers with nobody home, dealing with the problem at a few mail servers handling authenticated mail submission is significantly different than fixing millions of end-user PC's sending mail to any other system on the Internet.
jm> Date: Fri, 25 Feb 2005 15:13:04 -0800 (PST) jm> From: just me jm> Internal users: With AUTH - correlate message with authenticated user, jm> then forbid mail transmission for them only. I'd rather do that than jm> slog through RADIUS logs. But, hey, maybe if I had more free time... jm> Increasing the detail of an audit trail doesnt mean anyone will jm> automatically use the information in an effective manner. Fingerprints and DNA analysis are equally useless, I suppose. jm> Without auth, most ISPs could correlate abuse behavior between MTA jm> logs and RADIUS logs, if they cared. Most don't. SMTP AUTH won't jm> change that. I guess it's probably fallacious to argue from the viewpoint of ISPs caring. Please pardon my Freudian slip. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Internal users: With AUTH - correlate message with authenticated user, then forbid mail transmission for them only. I'd rather do that than slog through RADIUS logs. But, hey, maybe if I had more free time...
Increasing the detail of an audit trail doesnt mean anyone will automatically use the information in an effective manner.
This is why we need an Internet Mail Services Association in which email operators set standards and agree on how to operate the Internet email transport system. This group would have the goal of providing a high quality email service to all users. If that quality standard includes maintaining and using an audit trail, then the association members will do so. You cannot solve email operational problems by purely technical means. --Michael Dillon
On Fri, Feb 25, 2005, Nils Ketelsen wrote:
It's so funny. On this list many argued Port 25 outgoing must be blocked only to notice, that users actually seem to need it to send mail. Now we must configure our mailservers to listen on 587 to circumvent these filters, that were stupid in the first place.
Now to my prophecy mode: Spammers will start using 587 to spam, which we then also all block outgoing, notice again that customers still want to send mail and open another port ... 652 maybe. But this in a "while (true)" loop until we run out of ports.
kind of. the reason port 25 is filtered is because spammers were making direct connections from (host) to (domain MX). This isn't distiguishable from normal SMTP except by things like SPF which authenticate the /sender/ host. port 587 is different - the spammers can use it but the spam now passes through your ISP configured mailserver. much like how spammers are sometimes poking the registry/configuration to use configured MTAs since direct connection to domain MX servers isn't always working. so yes, it'll eventually be used by spammers but, by its very nature, the spam source will be easily identified and throttled at their end. adrian -- Adrian Chadd "You don't have a TV? Then what's <adrian@creative.net.au> all your furniture pointing at?"
On Thu, 24 Feb 2005 17:14:17 EST, Jim Popovitch said:
If supporting one port is y hours of time and headache, then two ports is closer to y*2 than y (some might argue y-squared). 587 has some validity for providers of roaming services, but who else? Why not implement 587 behavior (auth from the outside coming in, and accept all where destin == this system) on 25 and leave the rest alone?
Well, OK. If you know for a *fact* that your users *never* roam, and you have sufficiently good control of your IP addresses that you can always safely decide if a given connection is "inside" or "outside" and allow them to relay based on that, then no, you don't need to support 587. The rest of us run mail services in the real world, where lots of users buy laptops, and then actually <gasp, shock> *use* the portability and thus often end up behind some other ISP's port-25 block.
On Thu, 2005-02-24 at 23:36 -0500, Valdis.Kletnieks@vt.edu wrote:
The rest of us run mail services in the real world, where lots of users buy laptops, and then actually <gasp, shock> *use* the portability and thus often end up behind some other ISP's port-25 block.
Why not a VPN solution. If you have mail servers that your users need, chances are that you also have file servers, internal web servers. calender servers, etc. Should file/web/calender servers all open one port or internal access and a second port for authenticated external access? -Jim P.
On Fri, Feb 25, 2005, Jim Popovitch wrote:
On Thu, 2005-02-24 at 23:36 -0500, Valdis.Kletnieks@vt.edu wrote:
The rest of us run mail services in the real world, where lots of users buy laptops, and then actually <gasp, shock> *use* the portability and thus often end up behind some other ISP's port-25 block.
Why not a VPN solution. If you have mail servers that your users need, chances are that you also have file servers, internal web servers. calender servers, etc. Should file/web/calender servers all open one port or internal access and a second port for authenticated external access?
It'd be nice. :) Although, its different for ISP access. An office, sure, a VPN is possibly the right solution. But your ISP email account? Why VPN to your ISP just for that? Adrian -- Adrian Chadd "You don't have a TV? Then what's <adrian@creative.net.au> all your furniture pointing at?"
On Fri, 25 Feb 2005 02:30:01 EST, Jim Popovitch said:
Why not a VPN solution. If you have mail servers that your users need, chances are that you also have file servers, internal web servers. calender servers, etc.
We're talking ISPs and other "mostly open" providers, not corporate nets. Remember that a *big* part is the support nightmare of getting your 50,000 Joe Sixpack subscribers to pull down a menu and change a 25 to a 587. And you intend to make them purchase, install, and configure a VPN?
Should file/web/calender servers all open one port or internal access and a second port for authenticated external access?
Last I heard, if you have "public" and "internal" web content, Best Practices says to put then not on different ports, but *different hosts* - the public one out in your DMZ, and your internal one on your internal network.
On Fri, Feb 25, 2005 at 02:30:01AM -0500, Jim Popovitch wrote:
On Thu, 2005-02-24 at 23:36 -0500, Valdis.Kletnieks@vt.edu wrote:
The rest of us run mail services in the real world, where lots of users buy laptops, and then actually <gasp, shock> *use* the portability and thus often end up behind some other ISP's port-25 block.
Why not a VPN solution. If you have mail servers that your users need, chances are that you also have file servers, internal web servers. calender servers, etc. Should file/web/calender servers all open one port or internal access and a second port for authenticated external access?
That might work for corporate networks, but not for hosting providers, isps, etc. We have about 10000 domains we manage, a lot of them have active mail users. Imagine a (low) average of 5 mailboxes per domain. That would mean my team would have to support 50000 VPN connections? No thank you! Furthermore, to setup a vpn, you need extra software, there are the issues when you are behind a NAT (or even double-NAT) etc. Almost all MUA's support auth-smtp on port 587, and thus this can be used from anywere (cyber-cafe when you are on holiday, pda's, even some cellphones, ...). BTW: Belgium's two biggest isps _do_ block tcp/25 outgoing... Kind Regards, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
On Thu, Feb 24, 2005 at 11:36:40PM -0500, Valdis.Kletnieks@vt.edu wrote:
Well, OK. If you know for a *fact* that your users *never* roam, and you have sufficiently good control of your IP addresses that you can always safely decide if a given connection is "inside" or "outside" and allow them to relay based on that, then no, you don't need to support 587.
The rest of us run mail services in the real world, where lots of users buy laptops, and then actually <gasp, shock> *use* the portability and thus often end up behind some other ISP's port-25 block.
I force anyone, who wants to relay to use SMTP-AUTH on port 25. Only mails for local delivery are accepted without AUTH. Whats point in opening another port? I use this mailserver from a lot of different networks and it works fine. If a provider blocks port 25 I call them, ask them to cahnge it, if they don't I cancel my contract, because they don't do there Job (forwarding IP). Nils
Nils Ketelsen wrote:
On Thu, Feb 24, 2005 at 11:36:40PM -0500, Valdis.Kletnieks@vt.edu wrote:
Well, OK. If you know for a *fact* that your users *never* roam, and you have sufficiently good control of your IP addresses that you can always safely decide if a given connection is "inside" or "outside" and allow them to relay based on that, then no, you don't need to support 587.
The rest of us run mail services in the real world, where lots of users buy laptops, and then actually <gasp, shock> *use* the portability and thus often end up behind some other ISP's port-25 block.
I force anyone, who wants to relay to use SMTP-AUTH on port 25. Only mails for local delivery are accepted without AUTH. Whats point in opening another port?
I use this mailserver from a lot of different networks and it works fine. If a provider blocks port 25 I call them, ask them to cahnge it, if they don't I cancel my contract, because they don't do there Job (forwarding IP).
Nils
Let us know how that goes the next time you are consulting at a cable-internet customer site with your laptop......yes you will use ssh. The priority of a network service provider should be in this order 1) Keep the network up 2) Keep the network un-abusive (this is a long-term extension of 1 because an internetwork of abusive networks wont last long) 3) Forward customers packets SO if they block outbound direct-to-mx port 25 spam, I would say they are doing their job very nicely indeed.
On 2/25/2005 10:51 AM, Nils Ketelsen wrote:
On Thu, Feb 24, 2005 at 11:36:40PM -0500, Valdis.Kletnieks@vt.edu wrote: I force anyone, who wants to relay to use SMTP-AUTH on port 25. Only mails for local delivery are accepted without AUTH. Whats point in opening another port?
There are lots of secondary benefits. One of my favorites is that I can reject mail session on port 25 from hosts that claim to be in my domain (all such mail is authenticated on port 587 or is coming from a pre-configured list of servers that already hit an exception, so any other connections on port 25 that HELO as ehsco.com are lying). There are lots of these kinds of non-trivial benefits. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, Feb 24, 2005 at 04:51:50PM -0500, andrew2@one.net wrote:
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your
Oh thats easy: It creates costs (for implementing it on the servers and clients) and produces no benefit.
MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing?
You are missing the operational costs (has to be included in the regular failover tests, has to be monitored, has to be fixed if something breaks etc.) Any system I introduce is increasing risks and costs. If there is no benefit to justify these, I won't do it. Nils
On Thu, 24 Feb 2005 16:51:50 EST, andrew2@one.net said:
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing?
You *don't* want to just forward 587 to 25. You want to to use SMTP AUTH or similar on 587 to make sure only *your* users connect to it as a mail injection service (unless, of course, you *want* to be a spam relay ;) The *real* problem is usually that the site is too clueless to figure out how to enable AUTH on 587, actually authenticate the user (which might involve something really complicated, like LDAP or RADIUS), and tell the script monkeys at first-level support what to tell the users.
Valdis.Kletnieks@vt.edu wrote:
On Thu, 24 Feb 2005 16:51:50 EST, andrew2@one.net said:
There seem to be many who feel there is no overwhelming reason to support 587. I can certainly see that point of view, but I guess my question is what reasons do those of you with that viewpoint have *not* to implement it? I just don't see the harm in either configuring your MTA to listen on an extra port, or just forward port 587 to 25 at the network level. Other than a few man-hours for implementation what are the added costs/risks that make you so reluctant? What am I missing?
You *don't* want to just forward 587 to 25. You want to to use SMTP AUTH or similar on 587 to make sure only *your* users connect to it as a mail injection service (unless, of course, you *want* to be a spam relay ;)
I guess my assumption was that SMTP AUTH was already configured on port 25. :-) That's how we're doing it -- I've opened up port 587 more as a move to help roaming users get around port 25 blocks imposed by various ISP's around the country than anything else. For us it was a fairly trivial change to make, which is why I was inquiring as to the apparent strenuous reluctance on the part of some to do the same. Andrew
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
Although RFC2476 was published in December 1998, its amazing how few mail providers support the Message Submission protocol for e-mail on Port 587. Even odder, some mail providers use other ports such as 26 or 2525, but not the RFC recommended Port 587 for remote authenticated mail access for users.
well, in sbc-dsl-land, port 25 and port 587 are blocked, but port 26 gets through. it seems bizarre that port 587 would ever be blocked, but when i encountered it, port 26 was my next choice. perhaps other e-mail providers had the same problem and used the same plan-b.
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
it's smtp that only works if you can authenticate. thus it's only useful for your own user population, and completely safe to leave open to the world (as long as your user population keeps their passwords safe, that is.) -- Paul Vixie
"Paul" == Paul Vixie <vixie@vix.com> writes:
Paul> well, in sbc-dsl-land, port 25 and port 587 are blocked, but Paul> port 26 gets through. I have a port-587 relay on my network which is used by some sbc-dsl-land users... they don't appear to be blocked -- Andrew, Supernews http://www.supernews.com
Paul Vixie wrote:
well, in sbc-dsl-land, port 25 and port 587 are blocked, but port 26 gets through. it seems bizarre that port 587 would ever be blocked
I suspect that was some kind of temporary aberration. SBC started blocking port 25 in the last two months, and during that time I've helped at least a dozen of our customers using SBC DSL switch their mail program settings from port 25 to port 587, with no trouble -- it worked in every case. I bet it works if you try it again now (as you say, blocking port 587 makes no sense). -- Robert L Mathews
(as you say, blocking port 587 makes no sense).
Let me get this straight... it makes no sense to block a port that will allow unlimited relaying of all sorts of malware by only verifying an easily purchased or stolen username and password? If someone uses a big-ISP network to forward business impacting malware thorough your small-biz email server, using questionably gained 587 credentials, who is going to get sued? Is it safe enough for the big-ISP to say "we just route whatever our customer de'jour sends"? I am against port blocking as much as the next guy, I just see port 587 as a disaster waiting to happen. ISP provided email credentials are universally transmitted in plain text. If an (insert any ISP here) employee can be arrested for selling email addresses to spammers, what keeps them from collecting and selling 587 credentials? I understand that ISPs are trying to find a roaming solution for your customers. I just want you to find one that is *better* than simple port-587-auth-before-open-relay. For starters I would recommend that 587 access NOT be enabled by default for all users. Let it be by special request, and even then with some "teeth" involved. -Jim P.
On Sat, 26 Feb 2005, Jim Popovitch wrote:
I am against port blocking as much as the next guy, I just see port 587 as a disaster waiting to happen. ISP provided email credentials are universally transmitted in plain text. If an (insert any ISP here) employee can be arrested for selling email addresses to spammers, what keeps them from collecting and selling 587 credentials?
If you limit port 587 sending to let's say 1000 email per day you probably cover 99.9% of all normal users, and you're very likely to catch the spammers abusing an account. -- Mikael Abrahamsson email: swmike@swm.pp.se
Nils Ketelsen wrote:
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote:
<snip>
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
For the above population good reasons include being able to properly support such users. An alternate port is already a neccessity with many current providers. And your benefit? You get to standardize your support for your users stranded behind a port 25 block. You get to treat all 587 connections as requiring authentication to succeed, and by mere fact of their existence, are authenticated. You get to add another line item/RFC to the list of services your enhanced commercial services support. You dont want to formalize support? OK then add this to your sendmail.mc, make a note on your change forms and have it done with. DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl DAEMON_OPTIONS(`Port=smtps, Name=MTAS, M=Eas')dnl ^ +-------------For sendmail 8.13+ And our benefit? We get an environment where 587 authenticated sending is the norm. We can turn on SPF. We can require users to use their "home isp" mail servers. We get MUA which default setup includes probing for TLS/SMTP AUTH 587 submission during setup. We all win. MTA implementors? If 587 is the norm, yet it allows un-authenticated direct-to-mx spam bombarding by default, it *will* be included in outbound port-25 blocks. And then it will lose its relevance. We all lose.
Nils
Date: Thu, 24 Feb 2005 16:08:42 -0500 From: Nils Ketelsen <nils.ketelsen@kuehne-nagel.com> To: nanog@merit.edu Subject: Re: Why do so few mail providers support Port 587?
On Tue, Feb 15, 2005 at 09:00:11PM -0500, Sean Donelan wrote: [ ... ]
What can be done to encourage universities and other mail providers with large roaming user populations to support RFC2476/Port 587?
Give a good reason. That is still the missing part.
From a "security" stance (well - partly ;D) I always like to emphasize that in "The Real World" port 25 is for traffic between MTA's *and* submission of mails to the local MTA. So to reduce the chance of one of my users abusing an Open Relay and to enforce corporate e-mail policies, only port 25 towards our mailserver is open.
Port 587 on the other hand is meant for "submission" by clients. The security implications of allowing my users to contact such a port are very very low. If someone won't secure his mailserver on port 587, that's something different, but substantially different than if it were insecure on port 25... Now if you turn that around, you see why we opted to support SMTP Auth on port 587 and have left our legacy mailhub running on port 25 ;) I have users roaming around the world - on "company" business. And my users also entertain the same kind of roaming users. Now, if I want to have my users be able to connect to my mailserver on port 587 from anywhere in the world, I should also allow guests over here to do the same to their mailserver on port 587. It works both ways after all ;)
Nils
Kind regards, JP Velders
On Sat, Feb 26, 2005 at 03:10:42PM +0100, JP Velders wrote:
From a "security" stance (well - partly ;D) I always like to emphasize that in "The Real World" port 25 is for traffic between MTA's *and* submission of mails to the local MTA. So to reduce the chance of one of my users abusing an Open Relay and to enforce corporate e-mail policies, only port 25 towards our mailserver is open.
I do not know about your E-Mail Policy, but normally it is either allowed to use an external mailserver or not. If it is allowed, I can as well allow Port 25 outgoing. If it is not I will block 25 and 587.
Port 587 on the other hand is meant for "submission" by clients. The security implications of allowing my users to contact such a port are very very low. If someone won't secure his mailserver on port 587, that's something different, but substantially different than if it were insecure on port 25...
An interesting theory. What is the substantial difference? For me the security implications of "allowing the user to bypass our mailsystem on port 25" and ""allowing the user to bypass our mailsystem on port 587" are not as obvious as they maybe are to you. Nils
On Mon, 28 Feb 2005 16:54:23 EST, Nils Ketelsen said:
An interesting theory. What is the substantial difference? For me the security implications of "allowing the user to bypass our mailsystem on port 25" and ""allowing the user to bypass our mailsystem on port 587" are not as obvious as they maybe are to you.
The big difference is that if they connect on outbound 25, they're basically unauthenticated at the other end. Port 587 "should be" authenticated, which means that the machine making the connection out is presumably a legitimate user of the destination mail server. If you're managing a corporate network, then yes, the distinction isn't that obvious, as you're restricting your own users. If you're running an ISP, you're being paid to *connect* people to other places, and making it more difficult than necessary is.. well... a Randy Bush quote. ;)
On Mon, Feb 28, 2005 at 05:13:35PM -0500, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Feb 2005 16:54:23 EST, Nils Ketelsen said:
An interesting theory. What is the substantial difference? For me the security implications of "allowing the user to bypass our mailsystem on port 25" and ""allowing the user to bypass our mailsystem on port 587" are not as obvious as they maybe are to you.
The big difference is that if they connect on outbound 25, they're basically unauthenticated at the other end. Port 587 "should be" authenticated, which means that the machine making the connection out is presumably a legitimate user of the destination mail server.
Okay, the main difference seems to be: 1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude. 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
If you're managing a corporate network, then yes, the distinction isn't that obvious, as you're restricting your own users. If you're running an ISP, you're being paid to *connect* people to other places, and making it more difficult than necessary is.. well... a Randy Bush quote. ;)
I agree. Just as I said: If the ISP blocks (and I do not care which port he blocks), then it's time to go and look for another ISP. If I buy Internet I do not want a provider that decides for me which parts of it I am allowed to use today and which I am not. "Wehret den Anfaengen" is the german saying, I currently cannot find a good translation for. Nils
On Tue, Mar 01, 2005 at 09:18:19AM -0500, Nils Ketelsen wrote:
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
Here in Belgium, the two biggest end-user (broadband) ISPs block tcp/25. Are you going to tell your users: "sorry, you should have taken another another access isp, take one of the very few ones left that don't block"? Kind Regards, Frank Louwers -- Openminds bvba www.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
On Tue, Mar 01, 2005 at 03:25:39PM +0100, Frank Louwers wrote:
On Tue, Mar 01, 2005 at 09:18:19AM -0500, Nils Ketelsen wrote:
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
Here in Belgium, the two biggest end-user (broadband) ISPs block tcp/25. Are you going to tell your users: "sorry, you should have taken another another access isp, take one of the very few ones left that don't block"?
I am in the lucky situation, where I decide, which providers my users get. Nils
On Tue, 01 Mar 2005 09:18:19 EST, Nils Ketelsen said:
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from.
That's not when you need a port 587 server...
Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
Port 587 is for when you take your laptop along to visit your grandparents, and they have cablemodem from an ISP that blocks port 25. Now which do you do: 1) Whine at your grandparents about their choice of ISP? 2) Not send the mail you needed to send? 3) Make a long-distance (possibly international-rates) call to your ISP's dialup pool? 4) Send it back to your own ISP's 587 server and be happy? (Hint - there's probably a good-sized niche market in offering business-class mailhosting for people stuck behind port-25 blocks - they submit via 587/STARTTLS and retrieve via POP/IMAP over SSL).
On Tue, 1 Mar 2005 Valdis.Kletnieks@vt.edu wrote:
On Tue, 01 Mar 2005 09:18:19 EST, Nils Ketelsen said:
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from.
That's not when you need a port 587 server...
Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
Port 587 is for when you take your laptop along to visit your grandparents, and they have cablemodem from an ISP that blocks port 25. Now which do you do:
1) Whine at your grandparents about their choice of ISP? 2) Not send the mail you needed to send? 3) Make a long-distance (possibly international-rates) call to your ISP's dialup pool? 4) Send it back to your own ISP's 587 server and be happy?
E) Log into the webmail service my ISP provides. Opening another port can too easily turn into a whack-a-mole game between you, the spammers and ISPs. There are myriad ways to allow roaming/emergency E-mail activities. Let's not get pigeon-holed here. Finally, after a week or so of reading this thread, I'm inclined to believe it's officially a holy war. Nobody's changing anybody's minds here it seems. It's two stationary camps arguing. Can it stop now? --Gar
(Hint - there's probably a good-sized niche market in offering business-class mailhosting for people stuck behind port-25 blocks - they submit via 587/STARTTLS and retrieve via POP/IMAP over SSL).
On Tue, 1 Mar 2005 09:18:19 -0500, Nils Ketelsen <nils.ketelsen@kuehne-nagel.com> wrote:
Okay, the main difference seems to be:
1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude.
I think you're right here.. There are a number of us who will endeavor to do it the "right way", and then there are others who will either not have the technical know-how, or just plain don't care..
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
For a commercial service, I agree. Commercial users are deemed "more intelligent" and should have the capability to set up services in a more secure manner. Residential users, however, are the general problem. Your average Joe User has no idea how email works other than merely clicking the send button and having the email appear magically at the other end. Most users don't have spyware or virus checkers either. All of this leads to a large group of general users who can be exploited and abused at-will. As an ISP, I find it necessary to block certain ports. I block port 25 outbound from my residential customers to prevent direct-to-mx spamming. Currently they can only use port 25 on my mailserver, but that will eventually change to only port 587 and port 25 will be completely blocked. I also block netbios and other similar services which were never intended as WAN protocols in the first place. And I haven't had a single complaint from any of my residential customers. I'm fairly confident that they're mostly unaware of these blocks even though they were announced in advance..
I agree. Just as I said: If the ISP blocks (and I do not care which port he blocks), then it's time to go and look for another ISP. If I buy Internet I do not want a provider that decides for me which parts of it I am allowed to use today and which I am not.
You would be one of the smarter "Joe Users" who can handle the day-to-day nasties on the internet. Unfortunately, you're the minority... I wouldn't mind having an alternate service, with no change in pricing, that would allow users like you to have the freedom they want. In fact, if I had any demand for it at all, I'd set something up in a heartbeat.
"Wehret den Anfaengen" is the german saying, I currently cannot find a good translation for.
Nils
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com
Speaking on Deep Background, the Press Secretary whispered:
Okay, the main difference seems to be:
1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude.
Well, is authenticated SMTP 587 going to be worse than open port 25? I doubt it, but... In fact, I think most folks will do way better. Call that blind faith in the inhabitants of Middle Earth ^H^H^H NANOG....
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
So you will choose hotels, conferences, etc, by whether or not they block 25? And coming soon.. airlines! "That's right: aisle seat, low-sodium meal and NO port 25 blocking..." I do well to find out if the above has access at all, esp. if dealing through a reseller [hotels.com, etc]. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nils Ketelsen wrote:
On Mon, Feb 28, 2005 at 05:13:35PM -0500, Valdis.Kletnieks@vt.edu wrote:
On Mon, 28 Feb 2005 16:54:23 EST, Nils Ketelsen said:
An interesting theory. What is the substantial difference? For me the security implications of "allowing the user to bypass our mailsystem on port 25" and ""allowing the user to bypass our mailsystem on port 587" are not as obvious as they maybe are to you.
The big difference is that if they connect on outbound 25, they're basically unauthenticated at the other end. Port 587 "should be" authenticated, which means that the machine making the connection out is presumably a legitimate user of the destination mail server.
Okay, the main difference seems to be:
1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude.
I truly hope this isn't the case, I don't trust any mail server that I didn't personally configure.
2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users.
Yes, right up until a) ISPs wise up and start blocking port 587, and then 465 for good measure. or b) malware authors wise up. B will happen sooner. Chris - -- Chris Horry KG4TSM "You're original, with your own path zerbey@wibble.co.uk You're original, got your own way" PGP: DSA/2B4C654E -- Leftfield -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJM9FnAAeGCtMZU4RAvsFAKC5SvTVLS2VffMq2rcp7ZZZt4IGVwCgqbHO 2mSmy8GWV+l3xEzFsBBXp1o= =0wKT -----END PGP SIGNATURE-----
Chris Horry wrote:
Yes, right up until a) ISPs wise up and start blocking port 587, and then 465 for good measure. or b) malware authors wise up. B will happen sooner.
I completely agree, which is why if alternative SMTP injection ports are being used, some measure of authentication be used to authorize (or, in case of abuse, block) access. It isn't the magic bullet, and won't work forever, but in regards to the mail systems I maintain, it will do for now. -- Stephen Fulton.
Speaking on Deep Background, the Press Secretary whispered:
Yes, right up until a) ISPs wise up and start blocking port 587, and then 465 for good measure. or b) malware authors wise up. B will happen sooner.
Chris
Well, I'm no player in this league and ask... Why will ISP's ""wise up"" and block 587? If 587 is always auth'ed; then there will be no spam splashback provoking calls to block it. (Individual customers may get zombied; but that's easy to track and treat...) If a provider runs an open 587 port, and thus gets used as spam source; they will soon meet Mr. Linford and/or Mr. SPEWS. In either case, why will the clued ISP's want to block 587? -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On 03/01/05, David Lesher <wb8foz@nrk.com> wrote:
Well, I'm no player in this league and ask...
Why will ISP's ""wise up"" and block 587?
If 587 is always auth'ed; then there will be no spam splashback provoking calls to block it. (Individual customers may get zombied; but that's easy to track and treat...)
If a provider runs an open 587 port, and thus gets used as spam source; they will soon meet Mr. Linford and/or Mr. SPEWS.
In either case, why will the clued ISP's want to block 587?
I think the anti-587 logic here seems to be that we (we being the Internet community at large) shouldn't encourage anyone to ever act more responsibly than the worst operator because that worst operator will continue to be irresponsible. (I am only translating, not agreeing.) In any case, nobody has expressed any new ideas around this topic for about a week, so I'd suggest we let it drop before somebody mis-represents Godwin's Law. -- J.D. Falk uncertainty is only a virtue <jdfalk@cybernothing.org> when you don't know the answer yet
J.D. Falk wrote:
On 03/01/05, David Lesher <wb8foz@nrk.com> wrote:
Well, I'm no player in this league and ask...
Why will ISP's ""wise up"" and block 587?
If 587 is always auth'ed; then there will be no spam splashback provoking calls to block it. (Individual customers may get zombied; but that's easy to track and treat...)
Exactly.
If a provider runs an open 587 port, and thus gets used as spam source; they will soon meet Mr. Linford and/or Mr. SPEWS.
Ditto.
In either case, why will the clued ISP's want to block 587?
It makes no sense for clued ISPs to block 587. That 587 should be provisioned for unauthorized connections, or that clued ISPs should block 587 are both suggestions that make no sense.
I think the anti-587 logic here seems to be that we (we being the Internet community at large) shouldn't encourage anyone to ever act more responsibly than the worst operator because that worst operator will continue to be irresponsible.
(I am only translating, not agreeing.)
I'm not sure that I agree with this translation. I don't see *any* logic, just FUD as an excuse for failing to become educated about which problems 587 can help solve, the reduced problems that will exist when 587 is properly implemented by most networks, learning how easy it is to properly implement 587, educating your users about the benefits of using 587, etc. We saw all these same types of arguments (arguments due to implementation ignorance and fear of the support costs)10 years ago when we were trying to get networks to close open relays.
In any case, nobody has expressed any new ideas around this topic for about a week, so I'd suggest we let it drop before somebody mis-represents Godwin's Law.
Or take this topic to spam-l - where I feel it belonged in the first place. jc
Date: Mon, 28 Feb 2005 16:54:23 -0500 From: Nils Ketelsen <nils.ketelsen@kuehne-nagel.com> To: nanog@merit.edu Subject: Re: Why do so few mail providers support Port 587?
[ ... ] I do not know about your E-Mail Policy, but normally it is either allowed to use an external mailserver or not. If it is allowed, I can as well allow Port 25 outgoing. If it is not I will block 25 and 587.
Our corporate policy is that if you want to send mail with a @ourdomain address, you have to use our mailserver. On that machine we can rewrite usernames etc. But I have lots of users who also work at other places - to give you a hint, many of my users are researchers over here, but teachers at different places. So it's *not* in my employers best interest to disallow them *any* means of mailing with a @non-ourdomain address if that @non-ourdomain site allows them to do so via some other means then port 25...
Port 587 on the other hand is meant for "submission" by clients. The security implications of allowing my users to contact such a port are very very low. If someone won't secure his mailserver on port 587, that's something different, but substantially different than if it were insecure on port 25...
An interesting theory. What is the substantial difference? For me the security implications of "allowing the user to bypass our mailsystem on port 25" and ""allowing the user to bypass our mailsystem on port 587" are not as obvious as they maybe are to you.
Anything listening on port 587 - as has been said many times over in this discussion - should not blindly relay. It should demand authentication from the user and only when those are satisfactory relay. That was and is what port 587 is meant for. Port 25 has a much too diverse role in the way mail delivery is handled. But you can generally classify that it's used for inter-site communications and intra-site submission. Port 587 is for submissium, intra-site and extra-site. Just because you only allow port 80 inbound to the machines which are supposed to be running webservers doesn't mean you only allow outbound port 80 traffic to those same machines ? You would allow outbound port 80 traffic to the whole world...
Nils
Regards, JP Velders
participants (46)
-
Adrian Chadd -
Andrew - Supernews -
andrew2＠one.net -
Chip Mefford -
Chris Edwards -
Chris Horry -
Christopher X. Candreva -
Daniel Golding -
Daniel Senie -
Dave Crocker -
David Lesher -
Douglas Otis -
Edward B. Dreger -
Eric A. Hall -
Florian Weimer -
Frank Louwers -
J.D. Falk -
Jason Frisvold -
JC Dill -
Jeff McAdams -
Jim Popovitch -
Joe Maimon -
Joe Provo -
JP Velders -
just me -
Kee Hinckley -
Michael G -
Michael.Dillon＠radianz.com -
Mikael Abrahamsson -
Niels Bakker -
Nils Ketelsen -
Owen DeLong -
Paul Vixie -
Rich Kulawiec -
Robert L Mathews -
Sean Donelan -
Smoot Carl-Mitchell -
Stephane Bortzmeyer -
Stephen Fulton -
Steve Sobol -
Steven J. Sobol
-
Steven M. Bellovin -
Suresh Ramasubramanian -
Thor Lancelot Simon -
Todd Vierling -
Valdis.Kletnieks＠vt.edu