While performing functional tests on my company's newly-migrated Mail-eXchange/MX server, I found out that Swisscom (inOne Home Internet) intercepts all SMTP (port TCP/25) connections:
$ telnet <whichever-IP> 25
Connected to <whichever-IP>.
Escape character is '^]'.
220 nwas.lb.bluewin.ch vimdzmsp-nwas04.bluewin.ch Swisscom AG ESMTP server ready
[definitely not the legitimate SMTP server expected at <whichever-IP>]
And seamlessly relays e-mails presumably sent to that SMTP server via its own server (I can send you proof of this by private message if you wish); quite close to what one could call illegetimate man-in-the-middle...
In those days of SPAM, I can understand your willingness to control (potentially illegitimate) SMTP traffic on port TCP/25 (normally reserved for Mail-Transfer-Agents/MTA communications) but I would expect such connections to be rejected with a SMTP 5.x.x error code (and a human-friendly message, eventually displayed to the user by her Mail-User-Agent/MUA) rather than being silently relayed via some unsuspected (and unauthorized) third party.
Can you elaborate on this situation ?
Thanks in advance and best regards,
As said in the last post by @cdufour this is a man in the middle attack at my connection!
Even worse - instead of blocking the connection you send the mails from your own Mailserver (as shown in the email-header) which is definitly a Privacy issue...
Delivered-To: email@example.com Received: from nwas.lb.bluewin.ch (vimdzmsp-nwas04.bluewin.ch [188.8.131.52])
Running one's own MX (Mail Exchange) server - for one's own domain - which, when it acts as Mail Transfer Agent (MTA) to transfer messages to recipient MX servers (e.g. @protonmail.ch), MUST use the "unsecured" SMTP TCP/25 port, as per RFC 821 (Appendix A), further clarified (distinguished from Mail Submission Agent (MSA)) in RFC 2476 (Chapter 3.1), and explained on https://en.wikipedia.org/wiki/Message_transfer_agent
In the context of MTA, SMTP TCP/25 is thus *the* port to use and in not "unsecure" for modern-age MX/MTA servers, which will STARTTLS to enable end-to-end encryption of the transferred message(s), as per RFC 3207.
Swisscom acting as man-in-the-middle thus: 1. forfeits the purpose of STARTTLS and allows an unauthorited party (Swisscom) to see the "cleartext" content of the transmission (which it is not the intended recipient); 2. will break the Sender Policy Framework (SPF, RFC 4408) verification performed by the receiving MX/MTA server (since the relaying server - that of Swisscom - is *not* the authorized one for the sending domain).
Again, if Swisscom feels that SMTP TCP/25 is too much a SPAM (origin) threat for its *residential* customers (which can reasonably not be expected to run a MX/MTA server), it should either: A. reject all sending attempts with a STMP 5yz code (RFC 821, Appendix E); or B. Block the TCP/25 port altogether.
Of course, one wouldn't dare imagine Swisscom performing such man-in-the-middle for its *business* customers, whom one can very reasonably expect to run a MX/MTA server for their own IT purposes. (just curious, however...)