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 steven.glogger@swisscom.com ___________________________________________________________________________ Swisscom (Schweiz) AG Network & IT Network Engineering & Operations Binzring 17 CH-8045 Zürich www.swisscom.com
Steven.Glogger@swisscom.com 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.
Thanks for the extensive explanation!
One question there though: do you send a message to all customers actually stating that you are going to do this? Especially the content-inspection part which infringes on the freedom of speech and privacy of the people using your connectivity.
One can't expect them to go to the Swisscom website all the time thus a letter or at least an email is very appropriate.
As for the rest: (short: don't do content inspection) I fully agree with things that a lot of spam will come from DSL etc. BUT the part where you are effectively MITM connections, being judge on what people are allowed or not allowed to send(*) is a really really bad thing.
(* = I for instance send/receive viruses sometimes because I am taking a look at them, not because they are spreading. Same for spam, if you are postmaster@ or abuse@ then you need to look at them if you want to handle them.)
The really worrying part is the connection stealing. When you are able to do that for SMTP and especially as you are doing content inspection there (if you look at it as a person or not does not matter, something is looking at it and interpreting it), then you can also do it for HTTP and any other protocol.
I wonder what crack-pot of a government official will come next to then demand that you actually start doing that for port 80 too and start blocking sites which for instance say "UBS is bad" or "Switzerland sucks" and I don't know what, heck just on the "Host:" header.
Any kind of inspection is a bad thing and will cause some politician to make you do it for every other protocol: HTTP first, DNS later.
Which will in the end mean that the governments control the internets for the general folks and only the technically savvy people will be doing full crypto everywhere which at one point or another will then be banned out, nevertheless it will mean that we will not have a proper internet anymore, quite a shame of the country where WWW was invented.
Will we start to block completely port 25 in the future? No, absolutely not.
I rather have that you actively block port 25 without any inspection and just like you are offering now allow people to request the port to be opened. This avoids the whole legal issue with doing a MITM.
Yes, it will raise the support cost too as customers who are not using SUBMISSION over port 587 as they are supposed to will have problems. But your support folks can point to an easy URL where they can figure that out.
And actually the http://www.swisscom.com/p25 url which points to: http://www.swisscom.ch/res/hilfe/sicherheit/spam25/index.htm Already states that. It does *NOT* state that you are doing content inspection. Please keep it that way.
This method IMHO is pure infringement of privacy.
Please reconsider this setup and just block port 25 instead of doing this inspection.
A last nasty question: how do you guarantee that some person does not get access to the spam-filtering box and then can read along with almost every single email send on the Swisscom network?.... oh my...
Greets, Jeroen
I do agree on Jeroen's comment. Redirecting and doing content inspection is evil.
I've seen a similar case with a nation wide operator in another country. What they did was simply block port 25 except for their own mailserver. This might sound nasty but after all, all swisscom customers should use the bluewin mailserver except if they use some corporate server in which case they for sure want to use SSL and should be able to use the specific SSL port.
I think the most important thing to note is that endusers must know that the connection is limited for a specific reason (fighting spam distribution by customers) and that they can opt out if they have a specific need for it.
On 08.03.2010, at 13:49, Jeroen Massar wrote:
Steven.Glogger@swisscom.com 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.
Thanks for the extensive explanation!
One question there though: do you send a message to all customers actually stating that you are going to do this? Especially the content-inspection part which infringes on the freedom of speech and privacy of the people using your connectivity.
One can't expect them to go to the Swisscom website all the time thus a letter or at least an email is very appropriate.
As for the rest: (short: don't do content inspection) I fully agree with things that a lot of spam will come from DSL etc. BUT the part where you are effectively MITM connections, being judge on what people are allowed or not allowed to send(*) is a really really bad thing.
(* = I for instance send/receive viruses sometimes because I am taking a look at them, not because they are spreading. Same for spam, if you are postmaster@ or abuse@ then you need to look at them if you want to handle them.)
The really worrying part is the connection stealing. When you are able to do that for SMTP and especially as you are doing content inspection there (if you look at it as a person or not does not matter, something is looking at it and interpreting it), then you can also do it for HTTP and any other protocol.
I wonder what crack-pot of a government official will come next to then demand that you actually start doing that for port 80 too and start blocking sites which for instance say "UBS is bad" or "Switzerland sucks" and I don't know what, heck just on the "Host:" header.
Any kind of inspection is a bad thing and will cause some politician to make you do it for every other protocol: HTTP first, DNS later.
Which will in the end mean that the governments control the internets for the general folks and only the technically savvy people will be doing full crypto everywhere which at one point or another will then be banned out, nevertheless it will mean that we will not have a proper internet anymore, quite a shame of the country where WWW was invented.
Will we start to block completely port 25 in the future? No, absolutely not.
I rather have that you actively block port 25 without any inspection and just like you are offering now allow people to request the port to be opened. This avoids the whole legal issue with doing a MITM.
Yes, it will raise the support cost too as customers who are not using SUBMISSION over port 587 as they are supposed to will have problems. But your support folks can point to an easy URL where they can figure that out.
And actually the http://www.swisscom.com/p25 url which points to: http://www.swisscom.ch/res/hilfe/sicherheit/spam25/index.htm Already states that. It does *NOT* state that you are doing content inspection. Please keep it that way.
This method IMHO is pure infringement of privacy.
Please reconsider this setup and just block port 25 instead of doing this inspection.
A last nasty question: how do you guarantee that some person does not get access to the spam-filtering box and then can read along with almost every single email send on the Swisscom network?.... oh my...
Greets, Jeroen
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Steven.Glogger@swisscom.com wrote: Hi everyone Will we start to block completely port 25 in the future? No, absolutely not.
I rather have that you actively block port 25 without any inspection and just like you are offering now allow people to request the port to be opened. This avoids the whole legal issue with doing a MITM.
People are just too ... uneducated... to really get to the grips with this port 587-stuff. Blocking port 25 for *everybody* will just help to induce one shitstorm of a support-nightmare. It doesn't even make a difference if you have a grace-period or not (people ignore this stuff anyway). Steven can probably provide numbers about how many people are still using 25 vs. 587. It's probably millions. What happens if millions of people call the support-hotline....?
Yep, I hate the privacy implications. But with 100k abuse complaints/month - what would you do, besides going postal?
The only thing that could be done is a government-mandate to cut-off people with zombies in their LANs from the net and have a state-licensed PC-techie come over and clean-out the PC(s). For 200 CHF per hour. Plus 37 CHF court costs and administrative fees. ;-)
It works for cars, so it should work for PCs, too, right? ;-)
Rainer
Some ISP are already filtering port 25 for all customer and will unlock it on request (AS44885 to only name one I know). As far as I heard, it is the cheapest, most efficient way to do this with best results and it does not tackle the "oh-don't-touch-my-privacy" issue that I understand anyway.
Please reconsider this setup and just block port 25 instead of doing this inspection.
Let's be savvy. That is the best option for everybody. It is just funny to notice that it is always the same people that will suffer from spam and it will always create profits for others, not only spammers, but also people that can sell products and services to fight against - think of the millions Postini, MXLogic, Messagelabs, Ironport, Websense and all other AV/AS/App. solutions made out of that.
Yep, I hate the privacy implications. But with 100k abuse complaints/month
- what would you do, besides going postal?
Let's find good in bad. At least this creates work. Just think about the whole project lifecycle: projects manager -> quality committee -> PR/marketing -> designers -> network team and -> first-line support staff.
Gregory
Let's be savvy. That is the best option for everybody. It is just funny to notice that it is always the same people that will suffer from spam and it will always create profits for others, not only spammers, but also people that can sell products and services to fight against - think of the millions Postini, MXLogic, Messagelabs, Ironport, Websense and all other AV/AS/App. solutions made out of that.
That is why I started http://scavenger.exa.org.uk/ used with BGP FlowSpec to redirect traffic it should spam nicely http://bgp.exa.org.uk/ It is just a pity, I do not much time to work on the code atm, but will surely later on this year.
Thomas
Spam coming through Bluewin ADSL is not something new. Doing whatever action to stop spam in an early stage (aka years ago) would not had result in a shitload of support calls. But the guys at Swisscom waited long enough to implement this, so they don¹t deserve my empathy...
I know enough ISPs which implemented the ³forced own SMTP² already on dial-in accesses (so you see which decade I¹m talking about).
Finally I just wonder which alternative ISP will the swiss-spammers choose to continue to mess up the internet. Keep looking your spam-filter logs for a mass shift :-)
Daniele
On 3/8/10 2:26 PM, "rainer@ultra-secure.de" rainer@ultra-secure.de wrote:
Blocking port 25 for *everybody* will just help to induce one shitstorm of a support-nightmare. It doesn't even make a difference if you have a grace-period or not (people ignore this stuff anyway). Steven can probably provide numbers about how many people are still using 25 vs. 587. It's probably millions. What happens if millions of people call the support-hotline....?
Yep, I hate the privacy implications. But with 100k abuse complaints/month
- what would you do, besides going postal?
The only thing that could be done is a government-mandate to cut-off people with zombies in their LANs from the net and have a state-licensed PC-techie come over and clean-out the PC(s). For 200 CHF per hour. Plus 37 CHF court costs and administrative fees. ;-)
It works for cars, so it should work for PCs, too, right? ;-)
Rainer
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2717 - Release Date: 03/07/10 20:34:00
This e-mail, any associated files and the information contained in them are confidential and is intended for the addressee(s) only. If you have received this message in error please notify the originator and delete the email immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. E-mails to and from the company are monitored for operational reasons and in accordance with lawful business practices. Any opinions expressed are those of the individual and do not necessarily represent the views of the company. The company does not conclude contracts by email and all negotiations are subject to contract. We make every effort to maintain our network free from computer viruses but accept no responsibility for any viruses which might be transferred by this e-mail.
I do not think that there are so many spammers located in Switzerland. Actually, I don’t think that there are so many spammers on earth at all, I rather think that a very few guy bother a very wide number of innocent and legitimate email users. However Switzerland is probably a good place to infect computers, since the infrastructures are probably of good standing.
I am amazed every single time I see figures about emails with the actual number of “clean” emails sent a day. It seems quite funny to imagine that with all ideas that came out to filter spam we still see a high number of spams going on. The challenge is to find a fair way to stop that without to make the technology or protocol dependent on third-parties that would be partial. Actually I see spam and DDoS quite in the same way, both witness big flaws in how hosts and ISP protect their networks (against) but don’t seem to see the same energy on how _not_ to become one source of such attacks.
2010/3/8 Daniele Guazzoni daniele.guazzoni@audatex.ch
Spam coming through Bluewin ADSL is not something new. Doing whatever action to stop spam in an early stage (aka years ago) would not had result in a shitload of support calls. But the guys at Swisscom waited long enough to implement this, so they don’t deserve my empathy...
I know enough ISPs which implemented the “forced own SMTP” already on dial-in accesses (so you see which decade I’m talking about).
Finally I just wonder which alternative ISP will the swiss-spammers choose to continue to mess up the internet. Keep looking your spam-filter logs for a mass shift :-)
Daniele
On 3/8/10 2:26 PM, "rainer@ultra-secure.de" rainer@ultra-secure.de wrote:
Blocking port 25 for *everybody* will just help to induce one shitstorm of a support-nightmare. It doesn't even make a difference if you have a grace-period or not (people ignore this stuff anyway). Steven can probably provide numbers about how many people are still using 25 vs. 587. It's probably millions. What happens if millions of people call the support-hotline....?
Yep, I hate the privacy implications. But with 100k abuse complaints/month
- what would you do, besides going postal?
The only thing that could be done is a government-mandate to cut-off people with zombies in their LANs from the net and have a state-licensed PC-techie come over and clean-out the PC(s). For 200 CHF per hour. Plus 37 CHF court costs and administrative fees. ;-)
It works for cars, so it should work for PCs, too, right? ;-)
Rainer
* on the Mon, Mar 08, 2010 at 08:15:44PM +0100, Gregory Agerba wrote:
However Switzerland is probably a good place to infect computers, since the infrastructures are probably of good standing.
Actually, Switzerland has a high Microsoft-density (much higher than Germany, for instance), which makes it a good target.
Cheers Seegras
Peter Keel wrote:
- on the Mon, Mar 08, 2010 at 08:15:44PM +0100, Gregory Agerba wrote:
However Switzerland is probably a good place to infect computers, since the infrastructures are probably of good standing.
Actually, Switzerland has a high Microsoft-density (much higher than Germany, for instance), which makes it a good target.
Which is why all those extremely well connected *nix boxes with that awesomely performant Apache setup running PHP with all those nice 'customer' scripts which are so easy to infect.... and send out loads and loads and loads of nonsense... much easier and faster than that Windows box which comes with a nice default firewall etc per default and is clickety click manageable for even the dumbest of people.
Every box has a flaw, given enough of them, they will be exploited and abuse. (incidentally see also my note from a few days ago which most likely had something of the above going on but in a different way....)
Greets, Jeroen
Short other question which is also important to answer I guess, something a lot of customers will want to know and something I want to execute today, as I simply do not want any content-inspection on my DSL link (no I do not think it is normal to have to VPN everything).
Steven.Glogger@swisscom.com wrote: [..]
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.
Where exactly can this be requested?
https://sam.sso.bluewin.ch has a 'Internet Security' option which is disabled, but I can't seem to find anything about this new P25 blocking.
Thus, what is the procedure?
And, yes, still cuddles to Swisscom for having proper working connectivity and for trying to fight spam, it just sets precedents for things that should not be possible.
Greets, Jeroen
Is there any chance Swisscom could change these antispam error messages to CLEARLY indidicate they are generated by the Swisscom servers?
If Swisscom customers try to send messages to our customers which may look spammy according to Swisscom's new spam filter, they get errors like this:
<snip> Folgende Empfänger konnten nicht erreicht werden: Fehler bei der SMTP-Kommunikation mit dem E-Mail-Server des Empfängers. Wenden Sie sich an Ihren Systemadministrator. <local exchange hostname> #5.5.0 smtp;554 554 Sie haben versucht ein E-Mail zu verschicken, das Merkmale eines Spam-E-Mails aufweist. Das E-Mail wurde deshalb nicht verschickt. Bitte formulieren Sie Ihre Nachricht persoenlicher oder kontaktieren Sie uns unter 0800 800 800. -- [...] </snip>
This message was sent from an Exchange with static ip but smarthosting over Swisscom. The part "SMTP-Kommunikation mit dem E-Mail-Server des Empfängers" is not true either (the recipient mailserver was never involved) - that is admittetly an exchange fault. Except for a phone number which the NDR's recipient sees and is likely unknown, there is no reference to Swisscom anywhere, causing unnecessary support cases at the wrong place.
Normally, Swisscom marketing likes to put their brand name wherever they can, so at least be consistent and put it in those messages where it actually helps ;-) . In addition, including a link to a FAQ explaining this behaviour would be fair to the users which are obviously not informed about these new measures.
Regards, Oli Schacher
Oli Schacher schrieb:
Is there any chance Swisscom could change these antispam error messages to CLEARLY indidicate they are generated by the Swisscom servers?
You seem to have got an old message somehow. I got one today from the first one of our customers which is affected and this one was stating quite clearly what's going on (including link to the explanation). I changed his Outlook to the submit port which works well (except that the account test button keeps teeling it doesn't work - but who cares about that one...).
Regards Peter
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, Steven.Glogger@swisscom.com 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 steven.glogger@swisscom.com ___________________________________________________________________________ Swisscom (Schweiz) AG Network & IT Network Engineering & Operations Binzring 17 CH-8045 Zürich www.swisscom.com
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
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, Steven.Glogger@swisscom.com 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 steven.glogger@swisscom.com ___________________________________________________________________________ Swisscom (Schweiz) AG Network & IT Network Engineering & Operations Binzring 17 CH-8045 Zürich www.swisscom.com
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-
Andreas Fink -
Daniele Guazzoni -
Gregory Agerba -
Jeroen Massar -
Marco Fretz -
Oli Schacher -
Peter Guhl -
Peter Keel -
rainer＠ultra-secure.de -
Steven.Glogger＠swisscom.com -
Thomas Mangin