Anyone else having strange "attachment lost" effects when delivering mails to @bluewin.ch accounts?
Hi folks!
It started about 2 weeks ago with one of our clients affected. In the meantime, the cases pile up here more and more. Some mails are completly lost after we deliver them to the bluewin MX, others 'only' loose their attachments. According to swisscom support, none of our mailservers are blocked / blacklisted there.
Is anyone else seeing such things?
Best wishes, Matthias
On 2010-11-19 16:19, Matthias Hertzog wrote:
Hi folks!
It started about 2 weeks ago with one of our clients affected. In the meantime, the cases pile up here more and more. Some mails are completly lost after we deliver them to the bluewin MX, others 'only' loose their attachments. According to swisscom support, none of our mailservers are blocked / blacklisted there.
Can you clarify, what are the source/destination IP and email pairs? Are you sending from inside swisscom/bluewin to the SMTP servers for bluewin.ch (you state the MX) with as source a non-swisscom/bluewin address, or are you trying to send mail from swisscom/bluewin through their SMTP servers from/to what address?
As a related thing, did you ask your customers if they where notified of http://www.swisscom.ch/p25 and if that maybe is affecting delivery of emails? It being 'transparent' and just meddling with your connection in the middle, it might just do all kinds of weird things that nobody has a sight on what it is doing. And, of course still no opt-out method. I heard that you have to call techsupport, but really, I don't look forward to hanging on a phone for hours trying to educate some layer-1 support person what email is.....
from that URL: "This filter now also checks e-mail from free e-mail providers such as GMX, Google Mail and Hotmail if the e-mail is sent from a Swisscom connection"
Clearly they are doing HTTP inspection as otherwise they would not even catch most likely a percentage of the spam being sent out over those providers which are all HTTP based, that while SMTP is barely an option that only few people know about...
As a solution: provide for your customers a service: World Wide Email Delivery system
aka port 587, SSL'd with accounts on it....
Greets, Jeroen
Hi Jeroen
I know about the sad Port-25 story, but that does not seem the point hier. The cases look like this:
user@DomainHostedAtMhs is sending a mail to our mhs mail relays to normaluser@bluewin.ch. This works as expected.
Our mailserver then forwards the mail to the MX hosts for @bluewin.ch domain. This works too, (no reject on smtp level) but the mail never appears in the inbox at normaluser@bluewin.ch OR it appears, but without attachments.
Our sending ip at mhs is 213.188.32.73.
Best wishes, Matthias
_________________________________________
mhs @ internet AG Zürcherstrasse 204, CH - 9014 St. Gallen Phone +41 71 274 93 93, Fax +41 71 274 93 94 http://www.mhs.ch _________________________________________
----- Original Message ----- From: "Jeroen Massar" jeroen@unfix.org To: "Matthias Hertzog" m.hertzog@mhs.ch Cc: swinog@swinog.ch Sent: Friday, November 19, 2010 4:41 PM Subject: Re: [swinog] Anyone else having strange "attachment lost" effects when delivering mails to @bluewin.ch accounts?
On 2010-11-19 16:19, Matthias Hertzog wrote:
Hi folks!
It started about 2 weeks ago with one of our clients affected. In the meantime, the cases pile up here more and more. Some mails are completly lost after we deliver them to the bluewin MX, others 'only' loose their attachments. According to swisscom support, none of our mailservers are blocked / blacklisted there.
Can you clarify, what are the source/destination IP and email pairs? Are you sending from inside swisscom/bluewin to the SMTP servers for bluewin.ch (you state the MX) with as source a non-swisscom/bluewin address, or are you trying to send mail from swisscom/bluewin through their SMTP servers from/to what address?
As a related thing, did you ask your customers if they where notified of http://www.swisscom.ch/p25 and if that maybe is affecting delivery of emails? It being 'transparent' and just meddling with your connection in the middle, it might just do all kinds of weird things that nobody has a sight on what it is doing. And, of course still no opt-out method. I heard that you have to call techsupport, but really, I don't look forward to hanging on a phone for hours trying to educate some layer-1 support person what email is.....
from that URL: "This filter now also checks e-mail from free e-mail providers such as GMX, Google Mail and Hotmail if the e-mail is sent from a Swisscom connection"
Clearly they are doing HTTP inspection as otherwise they would not even catch most likely a percentage of the spam being sent out over those providers which are all HTTP based, that while SMTP is barely an option that only few people know about...
As a solution: provide for your customers a service: World Wide Email Delivery system
aka port 587, SSL'd with accounts on it....
Greets, Jeroen
On 2010-11-19 16:51, Matthias Hertzog wrote:
Hi Jeroen
I know about the sad Port-25 story, but that does not seem the point hier.
Thought so, but always something to keep in the back of our minds.
The cases look like this:
user@DomainHostedAtMhs is sending a mail to our mhs mail relays to normaluser@bluewin.ch. This works as expected.
Our mailserver then forwards the mail to the MX hosts for @bluewin.ch domain. This works too, (no reject on smtp level) but the mail never appears in the inbox at normaluser@bluewin.ch OR it appears, but without attachments.
Our sending ip at mhs is 213.188.32.73.
The only thing I can think of is a mailcorruption on the mailplatform of bluewin in that case; especially when you get no errors back from their SMTP server. Only people who will be able to debug this thus is the Bluewin folks, I hope they have a disk-space full warning on their platform and are able to properly check where things go wrong....
Only thing that comes to my mind now is: are you reading the bluewin account with their webif or over POP3/IMAP/whatever?
Might be that a certain MIME structure is not properly parsed in the cases that there are missing attachments. Of course the mails which go missing altogether indicate a bigger issue at hand, seems Swisscom is having quite some issues lately... (3G down, etc)
Greets, Jeroen
Hello,
I got some similar issues with some of my customers, anyway, if someone found a good explanation, it would be great, as the end users wint accept that swisscom can be responsible of any errors at all ;)
regards, philippe Schlumpf
On Fri, 2010-11-19 at 17:08 +0100, Jeroen Massar wrote:
Hi Jeroen
I know about the sad Port-25 story, but that does not seem the point hier.
Thought so, but always something to keep in the back of our minds.
The cases look like this:
user@DomainHostedAtMhs is sending a mail to our mhs mail relays to normaluser@bluewin.ch. This works as expected.
Our mailserver then forwards the mail to the MX hosts for @bluewin.ch domain. This works too, (no reject on smtp level) but the mail never appears in the inbox at normaluser@bluewin.ch OR it appears, but
without
attachments.
Our sending ip at mhs is 213.188.32.73.
The only thing I can think of is a mailcorruption on the mailplatform of bluewin in that case; especially when you get no errors back from their SMTP server. Only people who will be able to debug this thus is the Bluewin folks, I hope they have a disk-space full warning on their platform and are able to properly check where things go wrong....
Only thing that comes to my mind now is: are you reading the bluewin account with their webif or over POP3/IMAP/whatever?
Might be that a certain MIME structure is not properly parsed in the cases that there are missing attachments. Of course the mails which go missing altogether indicate a bigger issue at hand, seems Swisscom is having quite some issues lately... (3G down, etc)
Greets, Jeroen
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi
Is anyone else seeing such things?
Yes, we see the same type of effect.
Our customers are on cybernet-xDSL connections and send their mails through smtp.cybernet.ch. I guess they must have a similar config as the bluewin smtp servers.
The mails simply get lost and never reache the destination mailserver. Sometimes a mail sent to multiple recipients (all on our mailservers) only reaches a few of them. I have no clue what kind of black magic is done on the cybernet smtp servers, but it's very frustrating. I didn't particularly monitor whether mails with and without attachements are affected in different ways.
Another thing I saw is that mails sent to an non-swisscom mailserver on port 25 (non encrypted but authenticated) got a "X-Achtung Spam: " inserted after the headers, causing it to be rejected by some final destination mailservers because the header is invalid (it's preceed by a blank line). That must be because of the smtp-session-highjacking the incumbant is doing.
Anyway, we have been very busy lately to move more and more customers to not only use our mailservers but certainly encrypt their connections as to avoid someone fussing with the payload. I've definitely lost any trust in the smtp service offered by the access providers.
Regards
Jean-Pierre
Hi jean-pierre
As you mention smtp.cybernet.ch -> please provide me offlist some more details (from mail address, recipient, time) and I can grep in the mailserver logfiles to find out what happend with our black-magic vodoo filters ,-)
-steven
-----Ursprüngliche Nachricht----- Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Jean-Pierre Schwickerath Gesendet: Freitag, 19. November 2010 17:16 An: swinog@lists.swinog.ch Betreff: Re: [swinog] Anyone else having strange "attachment lost" effects when delivering mails to @bluewin.ch accounts?
Hi
Is anyone else seeing such things?
Yes, we see the same type of effect.
Our customers are on cybernet-xDSL connections and send their mails through smtp.cybernet.ch. I guess they must have a similar config as the bluewin smtp servers.
The mails simply get lost and never reache the destination mailserver. Sometimes a mail sent to multiple recipients (all on our mailservers) only reaches a few of them. I have no clue what kind of black magic is done on the cybernet smtp servers, but it's very frustrating. I didn't particularly monitor whether mails with and without attachements are affected in different ways.
Another thing I saw is that mails sent to an non-swisscom mailserver on port 25 (non encrypted but authenticated) got a "X-Achtung Spam: " inserted after the headers, causing it to be rejected by some final destination mailservers because the header is invalid (it's preceed by a blank line). That must be because of the smtp-session-highjacking the incumbant is doing.
Anyway, we have been very busy lately to move more and more customers to not only use our mailservers but certainly encrypt their connections as to avoid someone fussing with the payload. I've definitely lost any trust in the smtp service offered by the access providers.
Regards
Jean-Pierre
-- HILOTEC Engineering + Consulting AG - Langnau im Emmental Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs Tel: +41 34 402 74 00 - http://www.hilotec.com/
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi Steven
As you mention smtp.cybernet.ch -> please provide me offlist some more details (from mail address, recipient, time) and I can grep in the mailserver logfiles to find out what happend with our black-magic vodoo filters ,-)
I'm afraid I have to apologize for suggesting that cybernet had magical skills. I have to blame myself for that one.
It seems that at least one cybernet mail server (mta02) is listed on sorbs and I found a script that was going through our mailserver's logs and null-routed ips present on blacklists and nonetheless sending high volumes of messages.
That's why I never saw the messages reaching our mailservers and why some got through and other didn't - depending on which relay they were taking.
mea culpa.
Regards
Jean-Pierre
-
Jean-Pierre Schwickerath -
Jeroen Massar -
Matthias Hertzog -
philippe Schlumpf -
Steven Glogger