Per G Posted July 29, 2006 Share Posted July 29, 2006 I have yet to receive a real complaint against real UCE spam sent out by a customer of ours. I have however seen many complaints (both SC and otherwise) as a result of many other much more 'innocent' things. The worst culprit by far is auto-responders that despite them being severely filtered in their input (they rarely get spam to respond to) sometimes do respond to spam, which includes some appearing to be sent from what turns out to be SC spamtraps. First of all, SC's advice about getting rid of auto-responders just doesn't help. In a commercial setting with many separate customers and email much more central than webpages, there's no way to do without them. Sure, the stupid "We have received your mail and will respond ASAP" can be easily skipped, but those informing customers of vacations and other abscenses cannot. Despite a consistent use of a generic support address our customers often write personal mails instead of support mails, and they just don't get that people sometimes isn't there. We've lost major customers because support mails written personally went unanswered. Thus the auto-responders. Now, while spamtraps generally is a good idea (heck, I even run one myself), bounces and auto-responses often land there due to the ever-present faking of sender email in all spam. Now, when one hits SC's spamtrap, things get interesting because a lot of people use SC as a front line blocking system (as RBLS originally were used, as opposed to scoring in a spamassassin-like setting), and mails start bouncing. Some spammers switch their sending email all the time, rarely resulting in more than one hit on SC's spamtraps, while others still run a joe-job like scheme resulting in thousand of bounces (and auto-responses) hitting a single innocent victim - or a spamtrap. I order to fix things we (the ISPs) need info on the violations. We need to know something about what hit the spamtrap. IP's and headers would be nice, just like in regular reports. Feel free to remove any info identifying the trap if that's an issue, but it would be nice to be able to (for instance) identify a non-filtered auto-responder, a new mailserver still configured to send bounces etc. With no information and about 3.000 possible servers to examine, it's impossible for me to actually do something about a SC spamtrap hit, and that's what this place is really about isn't it? - to make people/ISPs act to fix whatever broken system that caused the SC response. The generic solution of just getting rid of auto-responders often isn't possible, both due to customer demand and due to them being hard to find. Oh yeah, I should mention that the reason we cannot identify a specific server from the listed IP is that we run a gateway (actually a small cluster) that filters outgoing mail. Individual servers cannot send mail outside our firewalls; they have to smart-host it through the gateway. Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.