Hi SwiNOG subscribers, Hi Swisscom, As written in SMTP RFCs a mailserver sending to a mailserver should use port 25 and a client sending to a mailserver (submitting a composed message) should use submission port 587. So far the approach in general is a good one, but just the approach, the swisscom solution is quite bad.
In my opinion an internet service provider must not start filtering traffic from his internet access customers without notifying the customer about doing so. Why not? because it's not the provider's decision whether traffics is bad or not , as Jeroen Massar already said. What's next? Filtering all http because some websites might could be bad or unattractive? That's really not the way it should be guys! An SMTP error message with a description about what and why it's happening is not a notification to the customer. Normal end-users use to ignore error messages and click them away. Which is normally not the case with correct bounce messages, but a error-message from MITM transparent proxies is displayed directly in "Outlook". If Swisscom would have sent a letter or e-Mail stating that they will start filtering "ALL e-Mails send from any user" and that the user has the choice to disable the service then it would possibly be fine. back to the technical part: I think filtering e-mails (via mail proxies, etc.) at the source (especially in dial-in networks) is not the right way to stop spam. There are lot more virus-/trojan infected hosts in the internet than mail receiving mails servers. Therefore the effort to stop spam that way is much higher. Using selective greylisting on inbound mail servers takes care about spam originating in dial-in networks without causing any nameable load on the mail server. And please, don't tell me that greylisting is delaying e-mails. Good (selective, dynamic) greylisting is learning and does only affect e-mails from hosts with a bad or missing reverse lookup and these messages are surely spam anyway. So what should Swisscom do? Either inform your customers that you're content filtering all their e-mails or shutdown your MITM proxies, fully block outgoing port 25 to any excluding your swisscom mailrelays and inform your customers to use submission port if they use another mail service provider. Start filtering outgoing mail (post queue) on your relay servers. I would not be surprised if Swisscom ends up in newspapers or online magazines with this story ;-) best regards, Marco On Mon, Mar 8, 2010 at 1:16 PM, <[email protected]> wrote: > Hi everyone > > To officially talk about the "mail problems on port 25 with swisscom dsl" I > would like to give you some (technical) information. > > We had several needs to stop spam from our network: > - We're receiving about 30'000-100'000 abuse complaints per month (contains > multiple reports per case) > - Mail filtering on our infrastructure (our mail servers) are only catching > 20% of all spam sent from swisscom dsl - 80% is sent directly from the > customer lines. (source: http://www.maawg.org/port25) > - About 60% to over 90% of all mails sent over residential customer lines are > identified as spam. This is more than 10 millions spam emails per day (~375 > terabytes per year) > > The impacts are clear: > - Spam generates a quite high amount of cost within Swisscom (money, > personal, time, storage, data, etc.) > - Our reputation is getting bad > - We might get listed on blacklists (-> impact on legimite traffic) > - Customers are getting blocked (e.g. in sandbox) and are not happy > therefore (most of the customers are not realizing, that they are sending > spam, because they are virus-/trojan-infected) > > > So, what we did and what are we doing? > > We currently ran a pilot. The productive rollout which will affect all > customers will start this week and will take around 2 months until all > customers are migrated. Only (ex-)bluewin customers with dynamic adsl-lines > will be affected. > Swisscom has published an official statement on http://www.swisscom.ch/p25 > and modifies the error-message sent to the customer which will be more > clearer. > The pilot showed very clearly that this countermeasure is very effectful in > stopping outgoing spam. > > > Going to the technical part: > We're running a transparent proxy on port 25 (smtp) which gets communication > from any customer to any port 25 (Layer 4 redirect feature). > The proxy is analyzing the email and if it detects that spam has been sent he > will reject the connection by issuing an error message to the customer (the > mailclient will notice: smtp-error). If the mail is a normal and legitimate > email -> no problem: mail will be sent. We will even insert a > "received-from:" line in the header. If a bot/trojan is trying to send > emails, the customer will not notice. There are no mails beeing stored on the > filter server. All decisions are made on-the-fly. > Customers, which are virus-affected are handled by the standard abuse process > which we have in place (inform, quarantine in a sandbox, etc.). > > The option for layer 4 redirect is activated via radius - so it can be turned > off on request and the customer just has to reconnect. > For dynamic customers the option will be activated by default. > > Customers are asked to authenticate their smtp session and use the mail > submission port 587 (not filtered). > > So, will this affect non-smtp traffic on port 25? Unfortunately, yes. This > traffic will be lost. If the customer has a need to use port 25 for other > purposes than email he can request turning of the redirecting feature. > > If a customer usses SSL via port 25 does it work? No, it will be dropped. > Customers are kindly requested to use port 465 instead. > > If a customer uses smtp auth via port 25, will this work? He will receive a > smtp error like "sorry, smtp auth not possible. use 587" (error 573). > > Will we start to block completely port 25 in the future? No, absolutely not. > > > So, I hope things are now getting clearer ,-) > > Greetings > > -steven > > Steven Glogger > ___________________________________________________________________________ > Cisco CCIE#23778 > Network Engineer > > Telefon +41 44 294 58 41 > Mobile +41 79 277 92 35 > Fax +41 86 079 277 92 35 > [email protected] > ___________________________________________________________________________ > Swisscom (Schweiz) AG > Network & IT > Network Engineering & Operations > Binzring 17 > CH-8045 Zürich > www.swisscom.com > > > > > _______________________________________________ > swinog mailing list > [email protected] > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > _______________________________________________ swinog mailing list [email protected] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
