
Hi Justin (and all others on-list) I understand your grounds for blocking outbound SMTP for your customers (especially those on dynamic IP connections). It probably will do good to block infected customers that are spewing spam all over the world. However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them? Since these corporate types (I'm guessing here) are probably unaware of how to change their email client's SMTP configurations, chances are that blocking outbound SMTP will probably cause quite a lot of pain. After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP. Cheers -- ANG Kah Yik (bangky)

On Tue, 11 Mar 2008, Ang Kah Yik wrote:
Hi Justin (and all others on-list)
I understand your grounds for blocking outbound SMTP for your customers (especially those on dynamic IP connections). It probably will do good to block infected customers that are spewing spam all over the world.
However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them?
Since these corporate types (I'm guessing here) are probably unaware of how to change their email client's SMTP configurations, chances are that blocking outbound SMTP will probably cause quite a lot of pain.
After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP.
For what it's worth, that's what port 587 was created for. And wouldn't those corporate types require VPN to access the network? On top of that, most who "block" 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---

Hi Andy (and all who responded), Thanks for the heads-up on the redirection on SMTP traffic. I've yet to see an implementation of it but I agree that it's a possible solution. As for the issue I raised previously, perhaps corporate users isn't a good example but what about users of email services such as Gmail and the like? Some users do use the SMTP service instead of the web interface. But redirection should do the trick. And thanks to all who remind me about rfc 2476 - I'm not a mail admin so I'm not familiar with it but I'll read up on it. Andy Dills wrote:
And wouldn't those corporate types require VPN to access the network?
On top of that, most who "block" 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering.
Andy
--- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
For what it's worth, that's what port 587 was created for.

Those using Google for SMTP can still use their ISP's SMTP servers for outbound.... Frank -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Ang Kah Yik Sent: Monday, March 10, 2008 7:40 PM To: Andy Dills Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs Hi Andy (and all who responded), Thanks for the heads-up on the redirection on SMTP traffic. I've yet to see an implementation of it but I agree that it's a possible solution. As for the issue I raised previously, perhaps corporate users isn't a good example but what about users of email services such as Gmail and the like? Some users do use the SMTP service instead of the web interface. But redirection should do the trick. And thanks to all who remind me about rfc 2476 - I'm not a mail admin so I'm not familiar with it but I'll read up on it. Andy Dills wrote:
And wouldn't those corporate types require VPN to access the network?
On top of that, most who "block" 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering.
Andy
--- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
For what it's worth, that's what port 587 was created for.

Doesn't anyone RTFM before posting anymore? http://mail.google.com/support/bin/answer.py?hl=en&answer=13287 # Configure your client to match the settings below: Incoming Mail (POP3) Server - requires SSL: pop.gmail.com Use SSL: Yes Port: 995 Outgoing Mail (SMTP) Server - requires TLS: smtp.gmail.com (use authentication) Use Authentication: Yes Use STARTTLS: Yes (some clients call this SSL) Port: 465 or 587 There is no need to use smtp on port 25 with gmail. configure the client according to gmail's instructions and use 465 or 587. jc Frank Bulk - iNAME wrote:
Those using Google for SMTP can still use their ISP's SMTP servers for outbound....
Frank
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Ang Kah Yik Sent: Monday, March 10, 2008 7:40 PM To: Andy Dills Cc: nanog@merit.edu Subject: Re: Customer-facing ACLs
Hi Andy (and all who responded),
Thanks for the heads-up on the redirection on SMTP traffic. I've yet to see an implementation of it but I agree that it's a possible solution.
As for the issue I raised previously, perhaps corporate users isn't a good example but what about users of email services such as Gmail and the like?

On Mon, Mar 10, 2008 at 7:58 PM, Ang Kah Yik <mailinglist@bangky.net> wrote:
Hi Justin (and all others on-list)
I understand your grounds for blocking outbound SMTP for your customers (especially those on dynamic IP connections). It probably will do good to block infected customers that are spewing spam all over the world.
However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them?
vpns fix this...
Since these corporate types (I'm guessing here) are probably unaware of how to change their email client's SMTP configurations, chances are that blocking outbound SMTP will probably cause quite a lot of pain.
uunet dialup has blocked port25 in both directions since 2002... little to no complaints. (well, they may have received complaints since I left, but... thank John StClair for the work behind that filtering actually.)
After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP.
many config's actually just use WCCP to transparently redirect your smtp to an authorized SMTP server as Andy Dills points out. -Chris

Ang Kah Yik wrote:
However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them?
After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP.
Thanks for joining the discussion. Frankly I'd be surprised to find many corps with an externally-accessible SMTP server that would accept mail on tcp/25. The only way they'd do it is with SMTP AUTH which (hopefully) implies the use of SMTP TLS as well. I know of very few corps that actually do this. Most of the corps I can think of are either running Exchange and utilizing RPC over HTTP, simply point their users to their company's webmail server, or require that their users VPN back to HQ to access their internal MTA. The sites that I can think of with external user-accessible SMTP daemons are entities with highly technical users. They utilize SMTP AUTH, TLS, and the Mail Submission Port on tcp/587. I'm afraid they are in the minority though. The MSP port is the best way to get around the blocks with decent MTAs. Your local MTA's support for other non-standard mechanisms for relaying mail from untrusted networks may also help with this problem (RPC over HTTP). Other than that I don't think there's enough demand for outgoing SMTP from the masses to warrant not blocking it. Redirecting generally takes care of that anyway. Thanks for the input though. All thoughts are welcome. Justin
participants (6)
-
Andy Dills
-
Ang Kah Yik
-
Christopher Morrow
-
Frank Bulk - iNAME
-
JC Dill
-
Justin Shore