Giampaolo Tomassoni wrote:
Daniel J McDonald wrote:
...omissis...
How can I? From what I know about razor-revoke, it's the recipients
who are using razor and who get messages that razor tags as spam who
are the ones that run this.
Their recipients who are saying that their messages are being marked
spam are comcast e-mail users. We aren't marking them as spam, we
don't use Razor, and after learning about what's happened to them,
it's doubtful that we ever will.
Ted
For what I know, Razor works on message hashes (more or less like DCC and
IXHash do). So, the Cloudmark site doesn't supply any delisting tool because it
is not the source IP to get listed, but the spammy messages hashes.
Wikipedia has a decent enough explanation of how it works.
I don't even know details about how razor hashes the message, so it *may*
eventually be that some piece of message (like, in example, an automatic foot
sign, or an automatic logo image) triggers the razor plugin. I would suggest to
manage with the recipient to attempt razor-revoking the FP messages.
Well, I don't think this is possible since Cloudmark wraps the Razor
system in a blanket, the ISP that buys Cloudmark is never told that
Razor is behind it, and Comcast further wraps whatever Cloudmark
gives them, so that their own users don't know what it is that
Comcast uses for spam filtering (Comcast probably rebrands Cloudmark
as "comcast spam filter" or some such.)
I would presume, knowing Comcast, and knowing the average ability
of the typical Comcast e-mail user, that the razor-report and
rezor-revoke is being done silently, automatically, behind the
scenes. Perhaps when a user pulls a message out of their junk
mail folder, it razor-revokes it.
The customer already called Comcast and complained, they were told
essentially to do nothing and the system will fix itself eventually.
You could also attempt to get help at the Vipul's Razor list:
razor-us...@lists.sourceforge.net .
It's not really my problem, to be honest. In this scenaro we are
only assisting our customer with running their -own- mailserver,
the customer -isn't- using -our- mailserver. If they were, this
never would have happened.
The situation is your typical small-company-mentality of well we
have 15 employees here and Exchange is so superior that we are gonna
spend 10 thousand dollars on it, on a server for it, and on paying
someone (our ISP in this case) to put it together for us since we
don't know how it goes together - instead of merely paying our ISP
a nominal fee per year per mailbox hosted on a UNIX system. You cannot
argue with this logic, which is why we decided a long time ago we
wouldn't, and got into the on-site support business as well as the
ISP.
In actuality, in this situation it technically wasn't the mailserver
that actually got compromised, it was a desktop PC - but since the
desktops and exchange server are both behind a NAT, from the outside
world they are considered the same device.
Our role is that of a consultant - and we have to play ball by
their rules, not ours. Meaning that once the helpful people on this
list pointed me in the right direction so that I could figure out
what we were dealing with, the ball is now in our customers court.
They don't want to pay our labor to sit for hours on the phone with
Comcast tech support, and I can't blame them, I wouldn't either.
Ted
Regards,
Giampaolo
