well, actually.. it seems someone from us confirmed it in the comments of http://blog.neocid.li/?p=105 ... -steven

-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Thomas Mueller Sent: Wednesday, March 03, 2010 1:40 PM To: swinog@swinog.ch Subject: Re: [swinog] mail "problems - port 25 on swisscom dsl (works fine for at least me though)

Am Wed, 03 Mar 2010 13:26:26 +0100 schrieb Jeroen Massar:

...

Thomas Mueller wrote:

...

hi

customers phoned me that they could not send emails anymore. needed to switch to port 587.

Maybe there is something filtering between you and them. They should be using port 587 anyway which is supposed to be the submission port. Unless they are running a fullblown SMTP setup on a DSL link of course.

yeah, nothing against port 587, but blocking port 25 without informing customers BEFORE is not the way to go. (most) mail-clients use port 25 if you do not specify it manually.

maybe swisscom has reasons to do this - trojans/viruses sending spams maybe?

...

...

now heard from others that swisscom is blocking port 25 ??? what the heck is going on ?

Which "others" and what metrics do they have?

a colleague too got calls from customers not able to send mails anymore. take a look at this blog entry http://blog.neocid.li/?p=105

---

swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Steven.Glogger@swisscom.com wrote:

well, actually.. it seems someone from us confirmed it in the comments of http://blog.neocid.li/?p=105 ...

Quite interesting read. As that states, if I understand correctly, that per-default one gets into the group where outbound mail to non-swisscom boxes get filtered.

If one uses SMTP-AUTH over Port 25, all is fine and you get re-directed to port 587 and all is 'fine'.

I guess it only becomes active when you reset your DSL session (rock solid at my place thus that nearly never happens afaik) as I still have:

tcp 0 0 194.1.163.39:25 92.105.157.240:45506 ESTABLISHED

But there is a bigger issue with the above, if that is truely how it happens:

- It is not documented anywhere on the Swisscom side - It was not communicated to customers - It does not account for people doing TLS, which would make the connection crypted - More importantly: it sets a very dangerous precedent that Swisscom is hijacking connections.

The last one is the really worrying part.

I don't mind port-25 filtering too much (I actually would fully agree with sending ICMP Destination Port Admin Unreachable), as long as there is an easy&non-cost way to disable that.

Redirecting traffic though, and thus being able to read along now that is quite a very very bad thing.... and I truly hope that is not the case.

I do hope that Swisscom realises that by doing that they will never be able to claim anymore that they can't do packet inspection, because then they are doing so, and that is a very dangerous thing, for them, but also for the customer (I am sure IPS and Storage folks won't mind suddenly selling you lots of hardware though) and of course the government being able to require even weirder things (we want you to block website XYZ, you can look at the Host: header, just filter it out...); yes I know taps are possible, but that is passive and thus different from actively participating and thus modifying packets)

Also, it all is futile the moment botters grow up and start using TLS.

Any public or non-public comments on that, and more-over better, a way to put straight what is then truly going on? :)

Greets with Love & Cuddles (as Swisscom works perfectly fine for me), Jeroen

Thomas Mangin wrote:

...

• It is not documented anywhere on the Swisscom side
• It was not communicated to customers
• It does not account for people doing TLS, which would make the connection crypted
• More importantly: it sets a very dangerous precedent that Swisscom is hijacking connections.

You should as well try to see if Swisscom SMTP server still allows to send bounces.

I am not using a home DSL connection for spamming the world, thus for me no need to do so as I won't get bounces there. Heck, I probably am not blocked as there is no outbound port-25 traffic.

I stopped allowing my customer to use our SMTP for bounces as :

• MUA do no generate bounces
• MTA (exchange) using us as smart-host should not use us to send their backscatter.

Depends on the type of contract you have with them and what you sell them of course.

If you have an open relay using SUBMISSION then well that is your configuration mistake. Oh and yes there are a couple of botnets which know how to retrieve account details from well known mailclients and use those details from that host and of course from others in the botnet. The prime thing thus that the AUTH part adds is tracability, thus please do also enable the equivalent of postfix smtpd_tls_received_header and smtpd_sasl_authenticated_header in your MTA for tracing purposes. Handy for you and the rest of the world so that they can at least assume you are not the source but it most likely is just a single user (of course headers can be faked etc)

...

I do hope that Swisscom realises that by doing that they will never be able to claim anymore that they can't do packet inspection,

IANAL ... This is not packet inspection, it is transproxying of mail.

Ah yes, thus modifying packets inline is 'transproxying', nice term ;)

The point is that the moment you can "change" something you can also filter stuff and that can then be a precedent for 'governments' and more over those three letter acronym organizations to require you to do so.

There is legal exception for proxying in most countries.

That is the excuse that NNTP providers also use, doesn't make it so that they are then still generating the traffic, especially the fun part where when the proxy is cut off for an extended period of time the service keeps on working flawlessly.

...

Also, it all is futile the moment botters grow up and start using TLS.

Breaking TLS is a real issue with mail transproxy.

Coming to think of it, I have never heard of that concept before. google neither it seems.

Yes, there are things called Transparent Proxies, these handle Port 80 (HTTP) in general and ignore port 443 (HTTPS), they do not translate though, they proxy.

There is absolutely no reason why anybody would want to proxy mail though (unless you are the provider of the mailservice and you do so for load distribution reasons etc). The only 'reason' is thus interception and thus reading/modifying of mail, as they can't honestly 'cache' it in any way. (as they cannot know that another connection from a network which is not forced to using the transproxy is not modifying the maildir). As for outbound SMTP, there is nothing you can 'proxy' there either, thus calling it a 'proxy' is definitely a misnomer. Connection hijack is the only correct term that comes to mind, and there is nothing 'legal' about that unless you maybe are located in Iran or China.

Good that most of my connectivity is SSL/TLS based and more importantly IPv6 ;)

At least one wise lesson out of it all: explain your customers to use SUBMISSION, aka Port 587+TLS.

Greets, Jeroen

Am Mittwoch, den 03.03.2010, 13:40 +0100 schrieb Steven.Glogger@swisscom.com:

did they phoned to the hotline? maybe they sent spam or so and port 25 has been blocked in order to force the customer to use 587? is there any error message giving more information about problems on the customer side?

-steven

Jup, customers get this:

************* Ihre Nachricht hat einige oder alle Empfänger nicht erreicht. Betreff: "Betreff" Gesendet am: "Datum" "Uhrzeit"

Folgende(r) Empfänger kann/können nicht erreicht werden:

'empfaenger@example.net' am "Datum" "Uhrzeit" 573 573 Authentifizierte Verbindungen nicht moeglich. Bitte nutzen Sie den Port 587 oder kontaktieren Sie uns unter 0800 800 800. ****************

Cheers

Chris