Shaw is now blocking OUTGOING port 25 (SMTP) to anything except their own mail server (shawmail.wp.shawcable.net). This is similar to what MTS did about a year ago.
This is only affecting one of my customers right now, so you may or may not be affected already. The Shaw rep says that it should be affecting all non-business-class customers. Obviously that's baloney because my personal home system still has working port 25 access.
Incoming port 25 appears to be open (unlike MTS which for some retarded reason thinks incoming port 25 is a spam risk).
As when MTS did this, I think it's complete nonsense and a clear example of net bigotry. Complain to your Shaw rep today!
On 22-May-07, at 10:02 PM, Trevor Cordes wrote:
Shaw is now blocking OUTGOING port 25 (SMTP) to anything except their own mail server (shawmail.wp.shawcable.net). This is similar to what MTS did about a year ago.
This is only affecting one of my customers right now, so you may or may not be affected already. The Shaw rep says that it should be affecting all non-business-class customers. Obviously that's baloney because my personal home system still has working port 25 access.
Incoming port 25 appears to be open (unlike MTS which for some retarded reason thinks incoming port 25 is a spam risk).
As when MTS did this, I think it's complete nonsense and a clear example of net bigotry. Complain to your Shaw rep today!
While I agree it is inconvenient, I would have to disagree that it is nonsense or 'net bigotry'. After watching my mail server logs, I honestly have to say that I wish _All_ ISP's did this to some extent. The fact that probably 50% (if not more) of the spam hitting my mail servers comes from consumer DSL/Cable lines is reason enough to block it IMHO.
Being both a SysAdmin and operating a hosting company, it is a pain for me to explain to clients how to send mail with Shaw or MTS's (or SBC or whichever ISP they are with) SMTP server and receive mail with my POP/IMAP servers, I still think it's for the better.
And I am with Shaw, but I have been using an SSH tunnel to check my mail for a few years now, so it's no big deal to me.
shawn
What he said.
Look at the situation from their perspective, this is the literally cheapest way to solve a problem and this will only affect a small minority of their customers. While this annoys me I understand it, though it would be nice to request that the block be removed without having to pay a 'business- class' premium.
The general rule of thumb is to always use the DNS and SMTP relay of your immediate upstream provider anyways. If it is a privacy issue then there are easy ways (for the technically savvy) around it (ie. -L25:127.0.0.1:25).
Was there any notification of the change? I don't see my bill anymore and have never used their mail system so I can't assume they just didn't go all commando. If there was no notification then I'm very sad and wonder why they have such terrible administration policies.
On 23-May-07, at 7:14 AM, Shawn Wallbridge wrote:
While I agree it is inconvenient, I would have to disagree that it is nonsense or 'net bigotry'. After watching my mail server logs, I honestly have to say that I wish _All_ ISP's did this to some extent. The fact that probably 50% (if not more) of the spam hitting my mail servers comes from consumer DSL/Cable lines is reason enough to block it IMHO.
Being both a SysAdmin and operating a hosting company, it is a pain for me to explain to clients how to send mail with Shaw or MTS's (or SBC or whichever ISP they are with) SMTP server and receive mail with my POP/IMAP servers, I still think it's for the better.
And I am with Shaw, but I have been using an SSH tunnel to check my mail for a few years now, so it's no big deal to me.
Well... yeah. Note that you can still do outbound SMTP if the destination SMTP server supports SSL/STARTTLS, such as smtp.gmail.com does: 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
So, it's not ideal as this won't be a solution which can be used by everyone affected, but at least it's something.
----- Original Message ----- From: Sean Cody sean@tinfoilhat.ca Date: Wednesday, May 23, 2007 10:33 am Subject: Re: [RndTbl] Shaw now blocking SMTP port 25
What he said.
Look at the situation from their perspective, this is the literally cheapest way to solve a problem and this will only affect a small minority of their customers. While this annoys me I understand it, though it would be nice to request that the block be removed without having to pay a 'business- class' premium.
The general rule of thumb is to always use the DNS and SMTP relay of your immediate upstream provider anyways. If it is a privacy issue then there are easy ways (for the technically savvy) around it (ie. -L25:127.0.0.1:25).
Was there any notification of the change? I don't see my bill anymore and have never used their mail system so I can't assume they just didn't go all commando. If there was no notification then I'm very sad and wonder why they
have such terrible administration policies.
On 23-May-07, at 7:14 AM, Shawn Wallbridge wrote:
While I agree it is inconvenient, I would have to disagree that
it
is nonsense or 'net bigotry'. After watching my mail server
logs, I
honestly have to say that I wish _All_ ISP's did this to some extent. The fact that probably 50% (if not more) of the spam hitting my mail servers comes from consumer DSL/Cable lines is reason enough to block it IMHO.
Being both a SysAdmin and operating a hosting company, it is a
pain
for me to explain to clients how to send mail with Shaw or
MTS's
(or SBC or whichever ISP they are with) SMTP server and receive mail with my POP/IMAP servers, I still think it's for the better.
And I am with Shaw, but I have been using an SSH tunnel to check
my
mail for a few years now, so it's no big deal to me.
-- Sean
-- Sean
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On 2007-05-23 11:41, Kevin McGregor wrote:
Well... yeah. Note that you can still do outbound SMTP if the destination SMTP server supports SSL/STARTTLS, such as smtp.gmail.com does: 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
Actually, there is a difference between TLS (or STARTTLS) and SSL. With SSL, encryption is enabled (or at least negotiated) right from the initial connection. An alternative port number is typically used for this reason. With TLS, the connection starts off in plain text, and encryption is (optionally) negotiated later, provided both sides support it. An alternative port number is usually not necessary for this.
Of course, if the whole point is to get around blocking of port 25, then an alternative port will be required, whether TLS or SSL is used.
So, it's not ideal as this won't be a solution which can be used by everyone affected, but at least it's something.
The problem with this is there isn't a clear standard for alternative ports for SMTP. So, you need to find out if your particular mail service supports it, and if so, on what port (and with what encryption options). Of course, if a standard (even de facto) were to emerge, it might just shift the spam problem to the other port, unless it only supports authenticated connections (which, I believe, required TLS support, not just SSL).
It wasn't clear from my message, but the part after "does:" was clipped from a Google Mail support page, including the bits in parentheses (for the record). Aside from that, it looks like you agree with me! :) I must learn to be less terse.
----- Original Message ----- From: "Gilbert E. Detillieux" gedetil@cs.umanitoba.ca Date: Wednesday, May 23, 2007 12:16 pm Subject: Re: [RndTbl] Shaw now blocking SMTP port 25
On 2007-05-23 11:41, Kevin McGregor wrote:
Well... yeah. Note that you can still do outbound SMTP if the destination SMTP server supports SSL/STARTTLS, such as
smtp.gmail.com does:
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
Actually, there is a difference between TLS (or STARTTLS) and SSL. With SSL, encryption is enabled (or at least negotiated) right from the initial connection. An alternative port number is typically used for this reason. With TLS, the connection starts off in plain text, and encryption is (optionally) negotiated later, provided both sides support it. An alternative port number is usually not necessary for this.
Of course, if the whole point is to get around blocking of port 25, then an alternative port will be required, whether TLS or SSL is used.
So, it's not ideal as this won't be a solution which can be used by everyone affected, but at least it's something.
The problem with this is there isn't a clear standard for alternative ports for SMTP. So, you need to find out if your particular mail service supports it, and if so, on what port (and with what encryption options). Of course, if a standard (even de facto) were to emerge, it might just shift the spam problem to the other port, unless it only supports authenticated connections (which, I believe, required TLS support, not just SSL).
-- Gilbert E. Detillieux E-mail: gedetil@muug.mb.ca Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609 _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
On Wed, 2007-05-23 at 10:33 -0500, Sean Cody wrote:
The general rule of thumb is to always use the DNS and SMTP relay of your immediate upstream provider anyways.
Yup but this is a serious pain in the *ss if you work constantly from a laptop like I do. You'd have to change the settings every time you move.
If it is a privacy issue then there are easy ways (for the technically savvy) around it (ie. -L25:127.0.0.1:25).
For the less savvy (like me) who don't use ssh tunnels that much (until now) here is the solution which I had to research today:
Make the following run at boot time and it will establish a ssh tunnel on a non-privileged local port (2525) using a non-privileged local user.
sudo -u localuser ssh -f -L 2525:127.0.0.1:25 -l remoteuser -N mail.remoteserver.com
Set your outbound SMTP for mail sending to 127.0.0.1:2525
John
On 23-May-07, at 6:09 PM, John Lange wrote:
On Wed, 2007-05-23 at 10:33 -0500, Sean Cody wrote:
The general rule of thumb is to always use the DNS and SMTP relay of your immediate upstream provider anyways.
Yup but this is a serious pain in the *ss if you work constantly from a laptop like I do. You'd have to change the settings every time you move.
Agreed. One thing I've done for a few $large_crown_corp people was run the services being blocked on high ports (ie. 25 -> 2525, 22 -> 2222). One amusing thing I've found is many $large_companies will block SSH but allow telnet so a nice solution is to listen sshd on both (or a simple redirect). There hasn't been a firewall yet that I could not break out from. :P
I was also reading an article a long while ago that suggested the possibility of distributing upstream service information via DHCP which I found interesting. Of course the dhcp client has to support it but that would make things VERY easy.
On 5/25/07, Sean Cody sean@tinfoilhat.ca wrote:
I was also reading an article a long while ago that suggested the possibility of distributing upstream service information via DHCP which I found interesting.
Sounds like a job for DNS SRV records...
(on a related note, the latest IP Protocol Journal has an excellent article on the DNS root servers: http://cisco.com/ipj)
Sean
According to that article; Canada has no root servers and no gTLD servers (except I assume gTLD .ca is here somewhere).
But I was certain that other article on a recent DNS DOS attack mentioned that Ottawa had a server?
John
On Fri, 2007-05-25 at 10:39 -0500, Sean Walberg wrote:
On 5/25/07, Sean Cody sean@tinfoilhat.ca wrote: I was also reading an article a long while ago that suggested the possibility of distributing upstream service information via DHCP which I found interesting.
Sounds like a job for DNS SRV records...
(on a related note, the latest IP Protocol Journal has an excellent article on the DNS root servers: http://cisco.com/ipj)
Sean
-- Sean Walberg sean@ertw.com http://ertw.com/ _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
I agree, I thought Ottawa had an anycast node from the ISC (f) root server...
[root@wpgnetsvc02 ~]# traceroute f.root-servers.net traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 40 byte packets ... 9 gw-isc.torontointernetxchange.net (198.32.245.23) 58.612 ms 22.422 ms 22.475 ms 10 f.root-servers.net (192.5.5.241) 23.249 ms 23.457 ms 23.758 ms
I don't know about any of the gTLDs (.com, .org), but the ccTLD for .ca is in Canada, I don't know the locations:
[root@wpgnetsvc02 ~]# dig foo.ca @f.root-servers.net ... ;; AUTHORITY SECTION: ca. 172800 IN NS CA04.CIRA.ca. ca. 172800 IN NS CA05.CIRA.ca. ca. 172800 IN NS CA06.CIRA.ca. ca. 172800 IN NS NS-EXT.ISC.ORG. ca. 172800 IN NS CA01.CIRA.ca. ca. 172800 IN NS CA02.CIRA.ca. ca. 172800 IN NS CA03.CIRA.ca.
On 5/28/07, John Lange john.lange@open-it.ca wrote:
According to that article; Canada has no root servers and no gTLD servers (except I assume gTLD .ca is here somewhere).
But I was certain that other article on a recent DNS DOS attack mentioned that Ottawa had a server?
John
On Fri, 2007-05-25 at 10:39 -0500, Sean Walberg wrote:
On 5/25/07, Sean Cody sean@tinfoilhat.ca wrote: I was also reading an article a long while ago that suggested the possibility of distributing upstream service information via DHCP which I found interesting.
Sounds like a job for DNS SRV records...
(on a related note, the latest IP Protocol Journal has an excellent article on the DNS root servers: http://cisco.com/ipj)
Sean
-- Sean Walberg sean@ertw.com http://ertw.com/ _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
John Lange wrote:
According to that article; Canada has no root servers and no gTLD servers (except I assume gTLD .ca is here somewhere).
.ca is a ccTLD so we do not have any gTLD servers in Canada(i.e. .info .biz, etc.)
But I was certain that other article on a recent DNS DOS attack mentioned that Ottawa had a server?
I think that was an F-root server.
-- Bill
I just had my first complaint from a notebook customer -- I see now what John was referring to.
I'm looking for an easy solution for my notebook-roaming customers to have access to SMTP (or encrypted variant). Can anyone suggest some tips or suggestions on setting up one of the following:
1. Having sendmail listen on 2 ports, 25 and (say) 26. Can I just add the 2nd (26) line to the .mc and sendmail will listen on both as opposed to just 25? Or is it a 25 OR 26 but not both type thing?
2. Set up SSL or TLS or whatever it's called this week in sendmail and have sendmail listen on both 25 and whatever other port. How easy is it to setup this stuff in sendmail on 20 mail servers? How easy is it to setup Outlook/OE to talk to sendmail in this way?
On 05/25/2007 11:13 AM, Trevor Cordes wrote:
I just had my first complaint from a notebook customer -- I see now what John was referring to.
I'm looking for an easy solution for my notebook-roaming customers to have access to SMTP (or encrypted variant). Can anyone suggest some tips or suggestions on setting up one of the following:
Having sendmail listen on 2 ports, 25 and (say) 26. Can I just add the 2nd (26) line to the .mc and sendmail will listen on both as opposed to just 25? Or is it a 25 OR 26 but not both type thing?
Set up SSL or TLS or whatever it's called this week in sendmail and have sendmail listen on both 25 and whatever other port. How easy is it to setup this stuff in sendmail on 20 mail servers? How easy is it to setup Outlook/OE to talk to sendmail in this way?
I don't have any experience setting up an SMTP server to support TLS or SSL, but the client-side setup is quite easy. For roaming access with a laptop computer, authenticated SMTP on an alternate port is definitely the preferred solution, if you have access to an SMTP server that supports it. (Fortunately for me, the U of M's main mail server does, so I didn't need to set it up myself.)
The client setup is described here for about 6 different common mail clients:
http://www.umanitoba.ca/computing/ist/applications/activekb/questions/133
On 23 May, Sean Cody wrote:
Look at the situation from their perspective, this is the literally cheapest way to solve a problem and this will only affect a small minority of their customers.
Ah, but it really only solves the problem if the majority of ISP's do the same, and even then the spammers will find some way around it eventually.
Was there any notification of the change? If there was no notification then I'm very sad and wonder why they have such terrible administration policies.
There was zero notification, just like when MTS did it. Just one day they unilaterally block a port.
-
Bill Reid -
Gilbert E. Detillieux -
Gilles Detillieux -
John Lange -
Kevin McGregor -
Sean Cody -
Sean Walberg -
Shawn Wallbridge -
Trevor Cordes