Hi all
Since Weeks we steadily get complaints from different customers (sometimes sending mail via our server, sometimes with own servers, sometimes using mailservers of other ISP) trying to send email to Bluewin Hostcenter Customers.
Their emails are being rejected by mail-fwd.mx.hostcenter.com.
The message from the Hostcenter Server ist: (reason: 554 Denied)
What I have found out since is: The Recipient uses the Hostcenter's anti-spam Solution. This is a 'blackbox solution' operated abroad, the Hostcenter Techs have no access to logfiles and there is not tech support abroad for that solution which could look into logs to tell what goes wrong.
It is impossible to find out why an email was rejected.
So the only thing I can tell our customers is: It's not working because the recipient is using a anti spam software which does not like your emails. Please communicate via fax or letter, just accept that email is not working and that we cannot fix it because the problem is at mail-fwd.mx.hostcenter.com and not our mailserver.
But the customers of course keep blaming us, because our server is 'not able to send mails to mail-fwd.mx.hostcenter.com'.
I wonder, are we the only ISP which gets this many complaints about emails not being accepted by mail-fwd.mx.hostcenter.com or are others also affected?
Mit freundlichen Grüssen
Benoit Panizzon
This is the main problem with hardware-based spam solutions -- they may seem simpler from the purchasing point of view, in that you (the provider) pay someone a fixed amount of money on a yearly subscription basis, and they (promise to) make your spam problems go away. Trouble is, they often fail to deliver on this promise.
Bluewin management seems to be the latest victim of this train-wreck thinking.
Any good spam solution will allow customer feedback into either a training or preferably a collaborative reporting system. The interface for this should ideally be closely integrated with the capabilities of intelligent mail clients. Yet the hardware solutions we looked at (such as Barracuda) seem to offer only a tedious-to-use web-based feedback interface. Tedious-to-use means it won't get used, so the system effectively becomes a black box.
SpamAssassin, an open source solution, has come a long way of late, though many operators don't use it correctly, or set it up as a black box, with no user reporting capability. It's highly tuneable, but many just take the default settings that are made available with the periodic updates. It can be set to provide extensive feedback as to why a mail was designated as spam. Mails identified as spam are not simply rejected; there is a good deal of user-configurable flexibility as to how they are handled.
Effective spam management became THE criterion for us in selecting a hosting provider for our corporate web and e-mail needs. We looked at several Swiss providers, and made our selection accordingly.
Charles
-----Original Message----- From: Benoit Panizzon [mailto:benoit.panizzon@imp.ch] Sent: Thursday, March 15, 2007 10:03 AM To: swinog@swinog.ch Subject: [swinog] Any others having troubles with mails being rejected by:mail-fwd.mx.hostcenter.com
Hi all
Since Weeks we steadily get complaints from different customers (sometimes sending mail via our server, sometimes with own servers, sometimes using mailservers of other ISP) trying to send email to Bluewin Hostcenter Customers.
Their emails are being rejected by mail-fwd.mx.hostcenter.com.
The message from the Hostcenter Server ist: (reason: 554 Denied)
What I have found out since is: The Recipient uses the Hostcenter's anti-spam Solution. This is a 'blackbox solution' operated abroad, the Hostcenter Techs have no access to logfiles and there is not tech support abroad for that solution which could look into logs to tell what goes wrong.
It is impossible to find out why an email was rejected.
So the only thing I can tell our customers is: It's not working because the recipient is using a anti spam software which does not like your emails. Please communicate via fax or letter, just accept that email is not working and that we cannot fix it because the problem is at mail-fwd.mx.hostcenter.com and not our mailserver.
But the customers of course keep blaming us, because our server is 'not able
to send mails to mail-fwd.mx.hostcenter.com'.
I wonder, are we the only ISP which gets this many complaints about emails not being accepted by mail-fwd.mx.hostcenter.com or are others also affected?
Mit freundlichen Grüssen
Benoit Panizzon
Charles Buckley wrote:
Any good spam solution will allow customer feedback into either a training or preferably a collaborative reporting system.
This is part of the solution we offer, but in truth, only very few, perhaps a handful endusers really use the feedback facilities. I agree it must be part of a good solution, but it's not as effective and as useful as one might think.
The interface for this should ideally be closely integrated with the capabilities of intelligent mail clients.
That would be perfect, but it's unrealistic. A customer is unlikely to want to install new software on e.g. 500 or 1000 PCs to enable an easy feedback.
/Per Jessen, Zürich
Per Jessen per.jessen@enidan.ch wrote:
The interface for this should ideally be closely integrated with the capabilities of intelligent mail clients.
That would be perfect, but it's unrealistic. A customer is unlikely to want to install new software on e.g. 500 or 1000 PCs to enable an easy feedback.
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter.
Then mail clients can support the interface out-of-the-box, and detect when they're behind a filter which provides this interface (namely, if all non-local messages come with that header, with a consistent value... if it's not consistent, the header is likely forged where present.)
Greetings, Norbert.
Norbert Bollow wrote:
Per Jessen per.jessen@enidan.ch wrote:
The interface for this should ideally be closely integrated with the capabilities of intelligent mail clients.
That would be perfect, but it's unrealistic. A customer is unlikely to want to install new software on e.g. 500 or 1000 PCs to enable an easy feedback.
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter.
Yes, something like that would be very good. Maybe we need to write an RFC for the "X-ReportSpam/Unwanted" header?
Per Jessen per.jessen@enidan.ch wrote:
Norbert Bollow wrote:
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter.
Yes, something like that would be very good. Maybe we need to write an RFC for the "X-ReportSpam/Unwanted" header?
Yes -- in order to achieve the widest possible support among email client vendors, the specification needs to be a standards-track RFC.
Of course then the header shouldn't be an X- header, i.e. it should be "ReportSpam:" or "ReportUnwanted:" without the "X-".
I like "ReportUnwanted:" better than "ReportSpam:" because even if the button in the email client is labelled "report spam", people will click it for any kind of mail that they want to stop receiving, they'll not stop to think whether the message fits any specific definition of spam.
Greetings, Norbert.
Norbert Bollow wrote:
Yes -- in order to achieve the widest possible support among email client vendors, the specification needs to be a standards-track RFC.
Definitely.
Of course then the header shouldn't be an X- header, i.e. it should be "ReportSpam:" or "ReportUnwanted:" without the "X-".
Yep, agree.
I like "ReportUnwanted:" better than "ReportSpam:" because even if the button in the email client is labelled "report spam", people will click it for any kind of mail that they want to stop receiving, they'll not stop to think whether the message fits any specific definition of spam.
Initially I thought the contents of this header should be a URL for accessing the filtering-providers website and report the email, but I think it would be better to have an email-address. Such that when the user clicks "Unwanted", the entire email is sent as an attachment to the address listed in "ReportUnwanted". That way the filtering provider will have all the necessary information to investigate the email, and the end user doesn't need HTTP access. Of course, we would need some sort of mechanism/authentication for preventing spammers from flooding (DoS) such a reporting address. Presumably a filtering provider would restrict the address to only receive reports from known customers' email-servers, but this will need some more thought.
/Per
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter.
Many mail clients (among them those of our favorite business software vendor...) won't display Mail-Headers in any usable form, probably not clickable anyway....
Cheers, Markus
True...
That's why there's this tool: http://www.xintercept.com/pkpeek.htm :-)
Cheers, Mike
-----Ursprüngliche Nachricht----- Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Markus Wild Gesendet: Freitag, 16. März 2007 15:04 An: Mike Kellenberger Cc: swinog@swinog.ch Betreff: Re: [swinog] Any others having troubles with mails being rejectedby:mail-fwd.mx.hostcenter.com
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter.
Many mail clients (among them those of our favorite business software vendor...) won't display Mail-Headers in any usable form, probably not clickable anyway....
Cheers, Markus _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Markus Wild wrote:
Therefore, the interface should be standardized, and the filter software should add a header, which provides an URL for the interface, to messages which pass through the filter.
Many mail clients (among them those of our favorite business software vendor...) won't display Mail-Headers in any usable form, probably not clickable anyway....
That's fine - the right way to treat such a header would be for the email-client to notice it, and present a special button or option for the user. Just like it reads the From: header and presents that in a nice way. But for that to happen, the "reportunwanted" header would have to be standardised first. And then accepted by the large email-client vendors ...
/Per Jessen, Zürich
-
Benoit Panizzon -
Charles Buckley -
Markus Wild -
Mike Kellenberger -
Norbert Bollow -
Per Jessen