It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network. I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon. AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is. One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot! Regards. -Zhiyun
We still do it and never get any complaints - we don't filter static IP customers but dynamic customers can either use our SMTP relays or alternate ports.... Paul -----Original Message----- From: Zhiyun Qian [mailto:zhiyunq@umich.edu] Sent: Thursday, June 18, 2009 3:37 PM To: nanog@nanog.org Subject: Is your ISP blocking outgoing port 25? It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network. I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon. AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is. One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot! Regards. -Zhiyun ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Do you provide your users an SMTP server to use, with some out bound spam filtering? It would seem this is to be expected, as you don't want your IP ranges showing up on RBL filters. Do you force SSL connectivity like AT&T does? Paul Stewart wrote:
We still do it and never get any complaints - we don't filter static IP customers but dynamic customers can either use our SMTP relays or alternate ports....
Paul
-----Original Message----- From: Zhiyun Qian [mailto:zhiyunq@umich.edu] Sent: Thursday, June 18, 2009 3:37 PM To: nanog@nanog.org Subject: Is your ISP blocking outgoing port 25?
It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network.
I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon.
AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is.
One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot!
Regards. -Zhiyun
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
We don't force SSL but do have several SMTP servers they can use.... -----Original Message----- From: Charles Wyble [mailto:charles@thewybles.com] Sent: Thursday, June 18, 2009 3:55 PM To: NANOG list Subject: Re: Is your ISP blocking outgoing port 25? Do you provide your users an SMTP server to use, with some out bound spam filtering? It would seem this is to be expected, as you don't want your IP ranges showing up on RBL filters. Do you force SSL connectivity like AT&T does? Paul Stewart wrote:
We still do it and never get any complaints - we don't filter static IP customers but dynamic customers can either use our SMTP relays or alternate ports....
Paul
-----Original Message----- From: Zhiyun Qian [mailto:zhiyunq@umich.edu] Sent: Thursday, June 18, 2009 3:37 PM To: nanog@nanog.org Subject: Is your ISP blocking outgoing port 25?
It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network.
I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon.
AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is.
One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot!
Regards. -Zhiyun
------------------------------------------------------------------------ ----
"The information transmitted is intended only for the person or entity
to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Zhiyun Qian wrote:
It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network.
Well blocking or redirecting to there servers, which have an undocumented filtering policy. All one needs to do in order to bypass that is use a vpn. Something lightweight like n2n could be used by the bot herders of the world. I worked for a company that sent out several hundred thousand messages per day (an online card/invitations company). We ran spam assassian on our outbound farm, to prevent folks from using us to send spam. I presume the large service providers do the same.
AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is.
It's trivial. A web form. You get the link when you try to send mail to port 25 anywhere else. At least with Yahoo/SBC dsl. I got the business class DSL from AT&T and no such nonsense exists.
AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is.
It's trivial. A web form. You get the link when you try to send mail to port 25 anywhere else. At least with Yahoo/SBC dsl.
I got the business class DSL from AT&T and no such nonsense exists.
Same here with U-Verse and a /29 of static IP's. No blocking since Day 1.
On Thu, Jun 18, 2009 at 03:36:44PM -0400, Zhiyun Qian wrote:
It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network.
Yes, it is standard practice for non-server accounts and most dynamic-only accounts; only allow unauthenticated smtp traffic to your own smtp servers. If you are not running server-to-server traffic at the end of that broadband pipe, then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote:
then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway...
Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections through some sort of lame proxy that connects you to your intended host, but strips the AUTH field out of the EHLO response from the remote submission server ...
On Thu, Jun 18, 2009 at 4:27 PM, Lyndon Nerenberg<lyndon@orthanc.ca> wrote:
On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote:
then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway...
Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections
port 26 FTW! in all seriousness, most isp's (consumer provider folk) today do some form of blocking of port 25, if you are 'smart' enough to evade this sort of thing, then you can still do email/blah. 99.999% of users are: 1) not interested in bypassing it 2) not clued into what's going on 3) using webmail Why is this debate still ongoing?? -Chris
Christopher Morrow wrote:
in all seriousness, most isp's (consumer provider folk) today do some form of blocking of port 25, if you are 'smart' enough to evade this sort of thing, then you can still do email/blah. 99.999% of users are: 1) not interested in bypassing it 2) not clued into what's going on 3) using webmail
I'd say 0.5% of my customer base contacts the helpdesk to setup auth and bypass tcp/25 blocks using tcp/587. Another 2% use my webmail offsite, and about 10% use webmail only (on my network or off). Then there's those pesky gmail users. We should just block them. j/k :P
Why is this debate still ongoing??
Because nanog is slow? Actually, I think the original poster was just curious as these days not much is said overly much outside of the "Die Spammer" threads in other venues. Jack
We just open port 2525 for customers from ISP's blocking official SMTP ports so they can use their dedicated servers/domain mailservers. Lyndon Nerenberg wrote:
On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote:
then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway...
Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections through some sort of lame proxy that connects you to your intended host, but strips the AUTH field out of the EHLO response from the remote submission server ...
-- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl
Sent from my iPhone, please excuse any errors. On Jun 19, 2009, at 8:53, Jeroen Wunnink <jeroen@easyhosting.nl> wrote:
We just open port 2525 for customers from ISP's blocking official SMTP ports so they can use their dedicated servers/domain mailservers.
Is there any reason you do not use port 587, SUBMIT? -- TTFN, patrick
Lyndon Nerenberg wrote:
On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote:
then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway...
Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections through some sort of lame proxy that connects you to your intended host, but strips the AUTH field out of the EHLO response from the remote submission server ...
--
Met vriendelijke groet,
Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl
telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes
Yes.. 1. Customers remember it more easily 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP port' in my previous comment ;-) Patrick W. Gilmore wrote:
Sent from my iPhone, please excuse any errors.
On Jun 19, 2009, at 8:53, Jeroen Wunnink <jeroen@easyhosting.nl> wrote:
We just open port 2525 for customers from ISP's blocking official SMTP ports so they can use their dedicated servers/domain mailservers.
Is there any reason you do not use port 587, SUBMIT?
-- TTFN, patrick
Lyndon Nerenberg wrote:
On Thu, 2009-06-18 at 16:14 -0400, Joe Provo wrote:
then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway...
Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections through some sort of lame proxy that connects you to your intended host, but strips the AUTH field out of the EHLO response from the remote submission server ...
--
Met vriendelijke groet,
Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl
telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes
-- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl
On Fri, 19 Jun 2009, Jeroen Wunnink wrote:
1. Customers remember it more easily 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP port' in my previous comment ;-)
Those same clueless ISPs will probably block 2525 someday too, clueless expands to fill any void. And using non-standard things like 2525 only lead to more confusion for customers later when they try someone else's non-standard choice, e.g. port 26 or 24 or 5252 and wonder why those don't work. On the other hand, why don't modern mail user agents and mail transfer agents come configured to use MSA port 587 by default for message submission instead of making customers remember anything? RFC 2476 was published over a decade ago, software developers should have caught up to it by now. Imagine if the little box in Outlook and Exchange had the MSA port already filled in, and you only needed to change it for legacy things.
Most MTAs don't come preconfigured with port 587 either. It is amazing how many people/organizations go with the "if it isn't broke, don't fix it" mentality, even though it clearly needs to be revised and something new needs to be done/supported. Email needs to be revamped on a larger scale than just adding standards. Sean Donelan wrote:
On Fri, 19 Jun 2009, Jeroen Wunnink wrote:
1. Customers remember it more easily 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP port' in my previous comment ;-)
Those same clueless ISPs will probably block 2525 someday too, clueless expands to fill any void. And using non-standard things like 2525 only lead to more confusion for customers later when they try someone else's non-standard choice, e.g. port 26 or 24 or 5252 and wonder why those don't work.
On the other hand, why don't modern mail user agents and mail transfer agents come configured to use MSA port 587 by default for message submission instead of making customers remember anything? RFC 2476 was published over a decade ago, software developers should have caught up to it by now. Imagine if the little box in Outlook and Exchange had the MSA port already filled in, and you only needed to change it for legacy things.
-- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Sean Donelan wrote:
On Fri, 19 Jun 2009, Jeroen Wunnink wrote:
1. Customers remember it more easily 2. Some ISP's also block 587 (hence 'SMTP ports' rather then 'SMTP port' in my previous comment ;-)
Those same clueless ISPs will probably block 2525 someday too, clueless expands to fill any void. And using non-standard things like 2525 only lead to more confusion for customers later when they try someone else's non-standard choice, e.g. port 26 or 24 or 5252 and wonder why those don't work.
On the other hand, why don't modern mail user agents and mail transfer agents come configured to use MSA port 587 by default for message submission instead of making customers remember anything? RFC 2476 was published over a decade ago, software developers should have caught up to it by now. Imagine if the little box in Outlook and Exchange had the MSA port already filled in, and you only needed to change it for legacy things. Better yet would be for the MUA to probe for the "best" configuration. Setting up mail is a royal PITA even if you know what you're doing. And a near death experience if you don't.
Mike
On the other hand, why don't modern mail user agents and mail transfer agents come configured to use MSA port 587 by default for message submission instead of making customers remember anything? Better yet would be for the MUA to probe for the "best" configuration.
The iPhone mail app will try 587 and then fall back to 25 if 587 doesn't work, which strikes me as a model for others to emulate. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Outlook supports Automatic Account Configuration, but unfortunately it seems to be only for Outlook, not OE or WM. It's a pity that MAAWG or another group hasn't written a specification for the automatic downloading of configuration (with certificates, to be sure, for some kind of repudiation) and the update thereof, for adoption by the leading consumer e-mail clients. Frank -----Original Message----- From: Michael Thomas [mailto:mike@mtcc.com] Sent: Tuesday, June 16, 2009 2:54 AM To: Sean Donelan Cc: North American Operators' Group Subject: Re: Is your ISP blocking outgoing port 25? <snip> Better yet would be for the MUA to probe for the "best" configuration. Setting up mail is a royal PITA even if you know what you're doing. And a near death experience if you don't. Mike
It's a pity that MAAWG or another group hasn't written a specification for the automatic downloading of configuration (with certificates, to be sure, for some kind of repudiation) and the update thereof, for adoption by the leading consumer e-mail clients.
MAAWG decided it's not in the standards business, but it does BCPs pointing at standards elsewhere (mostly the IETF) that it encourages people to follow. Write a standard that people can use, and I don't think I'd have much trouble getting them to endorse it. It's an interesting design topic, particularly the bootstrap question of how the client decides where to look for its configuration. A lot of this stuff is already available via DHCP, but of course a key goal here is to set config info the last across reboots on different networks. Followup to IETF-something, I suspect. R's, John
The bootstrap question is addressed by requiring the end-user to know their e-mail address and password. Based on the domain name, the implementation would reach out to https://something.domain-name.tld and download the relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. Based on what the e-mail client could support, the desired settings would be displayed, and upon end-user approval, applied. This could be leveraged by RIM for their BIS, Microsoft/Gmail/etc for smartphones, and for third-party webmail hosts such as mail2web.com Frank -----Original Message----- From: John Levine [mailto:johnl@iecc.com] Sent: Monday, June 22, 2009 9:24 AM To: nanog@nanog.org Cc: frnkblk@iname.com Subject: Re: Is your ISP blocking outgoing port 25?
It's a pity that MAAWG or another group hasn't written a specification for the automatic downloading of configuration (with certificates, to be sure, for some kind of repudiation) and the update thereof, for adoption by the leading consumer e-mail clients.
MAAWG decided it's not in the standards business, but it does BCPs pointing at standards elsewhere (mostly the IETF) that it encourages people to follow. Write a standard that people can use, and I don't think I'd have much trouble getting them to endorse it. It's an interesting design topic, particularly the bootstrap question of how the client decides where to look for its configuration. A lot of this stuff is already available via DHCP, but of course a key goal here is to set config info the last across reboots on different networks. Followup to IETF-something, I suspect. R's, John
It already is used by Microsoft. Do a google for +Microsoft +Autodiscover. It is used by Outlook for Windows, Entourage for Mac, the iPhone and Windows Mobile devices. Like you suggested, it uses DNS based on the users email address and looks for a series of resolvable addresses the easiest being autodiscover.domain-name.tld (it has others because of SSL cert flexibility). It uses that address to download an XML file. The only tricky thing to set it up is that a lot of the documentation out there is dated. It has changed since it was first released and a lot of the documentation on technical blogs, and even on Microsoft's web site are incorrect. Once it's setup, however, it's great. ---- Matthew Huff      | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax:  914-460-4139
-----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Monday, June 22, 2009 11:14 AM To: 'John Levine'; nanog@nanog.org Subject: RE: Is your ISP blocking outgoing port 25?
The bootstrap question is addressed by requiring the end-user to know their e-mail address and password. Based on the domain name, the implementation would reach out to https://something.domain-name.tld and download the relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. Based on what the e-mail client could support, the desired settings would be displayed, and upon end-user approval, applied. This could be leveraged by RIM for their BIS, Microsoft/Gmail/etc for smartphones, and for third- party webmail hosts such as mail2web.com
Frank
-----Original Message----- From: John Levine [mailto:johnl@iecc.com] Sent: Monday, June 22, 2009 9:24 AM To: nanog@nanog.org Cc: frnkblk@iname.com Subject: Re: Is your ISP blocking outgoing port 25?
It's a pity that MAAWG or another group hasn't written a specification for the automatic downloading of configuration (with certificates, to be sure, for some kind of repudiation) and the update thereof, for adoption by the leading consumer e-mail clients.
MAAWG decided it's not in the standards business, but it does BCPs pointing at standards elsewhere (mostly the IETF) that it encourages people to follow. Write a standard that people can use, and I don't think I'd have much trouble getting them to endorse it.
It's an interesting design topic, particularly the bootstrap question of how the client decides where to look for its configuration. A lot of this stuff is already available via DHCP, but of course a key goal here is to set config info the last across reboots on different networks.
Followup to IETF-something, I suspect.
R's, John
That’s e-mail client list covers less than 5% of my customer base and can't be construed as a standard. =) Even Microsoft doesn't support it in Outlook Express or Windows Mail. Frank -----Original Message----- From: Matthew Huff [mailto:mhuff@ox.com] Sent: Monday, June 22, 2009 10:20 AM To: 'frnkblk@iname.com'; 'John Levine'; 'nanog@nanog.org' Subject: RE: Is your ISP blocking outgoing port 25? It already is used by Microsoft. Do a google for +Microsoft +Autodiscover. It is used by Outlook for Windows, Entourage for Mac, the iPhone and Windows Mobile devices. Like you suggested, it uses DNS based on the users email address and looks for a series of resolvable addresses the easiest being autodiscover.domain-name.tld (it has others because of SSL cert flexibility). It uses that address to download an XML file. The only tricky thing to set it up is that a lot of the documentation out there is dated. It has changed since it was first released and a lot of the documentation on technical blogs, and even on Microsoft's web site are incorrect. Once it's setup, however, it's great. ---- Matthew Huff      | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax:  914-460-4139
-----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Monday, June 22, 2009 11:14 AM To: 'John Levine'; nanog@nanog.org Subject: RE: Is your ISP blocking outgoing port 25?
The bootstrap question is addressed by requiring the end-user to know their e-mail address and password. Based on the domain name, the implementation would reach out to https://something.domain-name.tld and download the relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. Based on what the e-mail client could support, the desired settings would be displayed, and upon end-user approval, applied. This could be leveraged by RIM for their BIS, Microsoft/Gmail/etc for smartphones, and for third- party webmail hosts such as mail2web.com
Frank
-----Original Message----- From: John Levine [mailto:johnl@iecc.com] Sent: Monday, June 22, 2009 9:24 AM To: nanog@nanog.org Cc: frnkblk@iname.com Subject: Re: Is your ISP blocking outgoing port 25?
It's a pity that MAAWG or another group hasn't written a specification for the automatic downloading of configuration (with certificates, to be sure, for some kind of repudiation) and the update thereof, for adoption by the leading consumer e-mail clients.
MAAWG decided it's not in the standards business, but it does BCPs pointing at standards elsewhere (mostly the IETF) that it encourages people to follow. Write a standard that people can use, and I don't think I'd have much trouble getting them to endorse it.
It's an interesting design topic, particularly the bootstrap question of how the client decides where to look for its configuration. A lot of this stuff is already available via DHCP, but of course a key goal here is to set config info the last across reboots on different networks.
Followup to IETF-something, I suspect.
R's, John
The bootstrap question is addressed by requiring the end-user to know their e-mail address and password. Based on the domain name, the implementation would reach out to https://something.domain-name.tld and download the relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. Based on what the e-mail client could support, the desired settings would be displayed, and upon end-user approval, applied.
End-user approval? That means support calls, ISPs wouldn't like that. I can believe something like this could be made to work, but I would think hard about all the way that web sessions can get screwed up or hijacked before I persuaded myself that a scheme was likely to work where it needed to work (e.g., when connecting to a hotspot that hijacks all web sessions until you log in) while not being subject to hostile spoofing. Followups definitely to IETF-something. R's, John
At 9:38 AM -0700 6/22/09, John R. Levine wrote:
The bootstrap question is addressed by requiring the end-user to know their e-mail address and password. Based on the domain name, the implementation would reach out to https://something.domain-name.tld and download the relevant "schema" and data for IMAP, SMTP, POP3, etc, in ordered priority. Based on what the e-mail client could support, the desired settings would be displayed, and upon end-user approval, applied.
End-user approval? That means support calls, ISPs wouldn't like that.
I can believe something like this could be made to work, but I would think hard about all the way that web sessions can get screwed up or hijacked before I persuaded myself that a scheme was likely to work where it needed to work (e.g., when connecting to a hotspot that hijacks all web sessions until you log in) while not being subject to hostile spoofing.
Followups definitely to IETF-something.
I would suggest following up at discuss@apps.ietf.org; the folks there can point you to things like RFC 2244 (ACAP, the Application Configuration Access Protocol), describe why that got turned in XCAP by the RAI area (RFC 4825, primarily used in SIP contexts but designed to be multi-use), and caution you that the many hours spent designing these things have not generally born fruit in the marketplace. Is this possible for email? Sure. With strong support from a vendor with a tied house model (e.g. RIM or Apple), it might even get to be popular. But as a general purpose approach, it has not hit that sweet spot. regards, Ted Hardie
R's, John
A colleague reports that Verizon and ATT have a cut cable in Camarillo, CA, in the vacinity of Lewis Road and Dawson. Anyone have more information on this outage? Thanks. matthew black e-mail postmaster california state university, long beach
Matthew Black wrote:
A colleague reports that Verizon and ATT have a cut cable in Camarillo, CA, in the vacinity of Lewis Road and Dawson. Anyone have more information on this outage? Thanks.
confirmed outage CalTrans went through an major fiber line, landlines, T1, Cell, and 911 are all down, in Oxnard, Camarillo, Thousand Oaks, etc... Vzw Fios is not affected VZW is on scene working on it, no ETA yet
Chaim Rieger wrote:
Matthew Black wrote:
A colleague reports that Verizon and ATT have a cut cable in Camarillo, CA, in the vacinity of Lewis Road and Dawson. Anyone have more information on this outage? Thanks.
confirmed outage
CalTrans went through an major fiber line, landlines, T1, Cell, and 911 are all down, in Oxnard, Camarillo, Thousand Oaks, etc...
Vzw Fios is not affected
VZW is on scene working on it, no ETA yet
See outages list for some discussion. Also http://twitter.com/socalincidents 911 is back up in Ventura.
Matthew Black wrote:
A colleague reports that Verizon and ATT have a cut cable in Camarillo, CA, in the vacinity of Lewis Road and Dawson. Anyone have more information on this outage? Thanks.
ETA for 4 PM for the fix sorry for the noise.
Matthew Black wrote:
A colleague reports that Verizon and ATT have a cut cable in Camarillo, CA, in the vacinity of Lewis Road and Dawson. Anyone have more information on this outage? Thanks.
outages.org P.S. It would be really cool not to open new topics under old threads.
We just open port 2525 for customers from ISP's blocking official SMTP ports so they can use their dedicated servers/domain mailservers.
for personal use, i have a box that has sshd running on 443 and i tunnel 2525 through it. that worked even in the narita red rug when they were at their blocking worst. for customer use, i would push them to 465, 587 if less clued. randy
On Thu, 18 Jun 2009, Lyndon Nerenberg wrote:
Except for those ISPs who choose to intercept port 587 as well. This is a big problem with Rogers in Vancouver. They hijack port 587 connections through some sort of lame proxy that connects you to your intended host, but strips the AUTH field out of the EHLO response from the remote submission server ...
Grr. Someone needs to whack them with the clue bat. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Joe Provo wrote:
On Thu, Jun 18, 2009 at 03:36:44PM -0400, Zhiyun Qian wrote:
It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network.
Yes, it is standard practice for non-server accounts and most dynamic-only accounts; only allow unauthenticated smtp traffic to your own smtp servers. If you are not running server-to-server traffic at the end of that broadband pipe, then you should be shifting your userbase to authenticated on the SUBMIT port [587] anyway...
The Messaging Anti-Abuse Working Group (MAAWG) published recommendations for managing port 25 traffic a few years ago, and even then it had already been a widely-accepted best practice for nearly a decade. http://www.maawg.org/port25 -- J.D. Falk Return Path Inc http://www.returnpath.net/
I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon.
You're mistaken. Comcast most certainly does port 25 filtering, although not necessarily on every line at every moment. So does Verizon, AT&T, and every other large North American consumer ISP I know. Look, kids, it's not 1998 any more. These days outgoing traffic to port 25 is approximately 99.9% botnet spam, 0.1% GWL, and 0% legitimate mail. Blame the botnet herders and the vendors of cruddy software that year after year still is full of trivial exploits. If you can make the botnets go away, I will be happy to lead the charge to unblock all those ports. If it's important to you to have an unfiltered connection, pay for business service that has a static IP, or arrange to tunnel to some host that does. R's, John
I am the ISP, and we currently don't. However, I inherited this setup and have been slowly fixing glaring holes (those are fairly well gone now) and not so glaring one. When our new firewall gets in, I will be rolling in port 25 blocks on dynamic IP addresses. The static ips will be unfiltered. Customers may send outbound mail through our SMTP server, or connect via alternate ports to their SMTP server. ________________________________ From: Zhiyun Qian [zhiyunq@umich.edu] Sent: Thursday, June 18, 2009 2:36 PM To: nanog@nanog.org Subject: Is your ISP blocking outgoing port 25? It has been long heard that many ISPs block outgoing port 25 for the purpose of reducing spam originated from their network. I wonder which ISPs are still doing so. I know comcast has been doing that but they cancelled it after many complaints. It seems to be the same case for Verizon. AT&T is the major one that I know of that is still enforcing this policy. But they said they can unblock port 25 upon request. I am not sure how easy it is. One simple way to test if your ISP is blocking outgoing port 25 is to try: "telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If the connection fails, it could be due to the fact your ISP is blocking outgoing port 25, although it can also be other reasons such as local firewall configuration. Can someone perform the test and let me know result if possible? Thanks a lot! Regards. -Zhiyun ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
participants (26)
-
Chaim Rieger -
Charles Wyble -
Christopher Morrow -
Dave Pooser -
Eric J Esslinger -
Frank Bulk -
J.D. Falk -
Jack Bates -
Jeroen Wunnink -
Joe Provo -
John Levine -
John R. Levine
-
Lyndon Nerenberg -
Matthew Black -
Matthew Huff -
Michael Thomas -
Patrick W. Gilmore -
Paul M Moriarty -
Paul Stewart -
Randy Bush -
Sean Donelan -
Seth Mattinen -
Steven King -
Ted Hardie -
Tony Finch -
Zhiyun Qian