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