Jump to content

Per G

  • Posts

  • Joined

  • Last visited

Per G's Achievements


Newbie (1/6)



  1. Yes, but also (and more important) how to locate them. I was requesting more info on spamtrap hits. Remember our setup where everything goes through a gateway which gets listed by SC as a spamtrap feeder. Our customers may put up one of them (auto-responders) on any server which may respond to potentially all spam, thus quickly causing a SC listing - not of the actual server but the gateway which affects all customers. Being told at SC that our gateway has sent mail to a spamtrap doesn't help at all because I'm always unable to locate the true source (the server behind the gateway). So I simply have to wait out the 24 hours doing nothing, potentially continuing the 'spam-attack', hoping that it stops on its own. I'd rather stop the thing immediately and have the gateway delisted, but I cannot stop what I cannot find. So the policy at SC shoots the cause (stopping spam and other unwanted emails) in the foot, crippling it.
  2. Well, my location is Denmark (in Scandinavia, Northern Europe) and while the basic premise here is that all mail handled by company servers belongs to the company just like in the US if I understand that correctly, there has been legal cases where an employee succesfully sued a workplace for breach of privacy because he was terminated based on what was learned from his personal mail. It was some form of discrimination (he was a closet homosexual if I remember correctly) which was only revealed due to the company reading his private emails. He won the case and a substantial settlement primarily due to the invasion of his privacy the company performed. The discrimination wasn't proved to be the sole reason of his termination. So it has ended up as a grey area - you own the mail but are not allowed to read it... That's why most employees here are encouraged to host their really personal mail elsewhere (gmail, own mailservers etc.). But there's still a need for one on one business contact, mostly because personal dialogues between someone else are just spam in everybody elses mailboxes if group addresses are used. And the minute you have a personal mailbox, the privacy rules apply, regardless of it actually being non-personal and pure business. Anyway, that was just some background for you, so let us let this one rest and get back on topic...
  3. Well, thank you dear spammers... Seriously, I cannot see how you could abuse the system when all you had available were the internal headers from the spamtrapped mail (and only one for each sending IP). Sure, by carefully comparing logs with the report from the spamtrap you might be able to deduce the domain and/or target email that were the spamtrap entry, but you'd only be able to find one spamtrap per hit per listing period (24 hours) so it would take forever to find much of anything. Clever spamtraps might also be working on specific target email adresses only (and not just a whole domain as normally done) so the spammers might even be blacklisting a whole domain when it's only a few specific email addresses that were the trap, thus easing the spam load on other addreses on the same domain. These special (clever) spamtraps are actually easy to create. My own spamtrap (coded from scratch by your truly) works this way. Once you have a regular spamtrap listening on port 25 on some IP, you simply forward those trap email addreses from a regular MTA to the spamtrap that is specially configured to go one step backwards when resolving the IP to be blacklisted, when the immidiate source is a specific IP which actually is the MTA hosting all the emails on that domain in question (the MX host). This way servers sending mails to trap[at]example.com get listed while those sending to johndoe[at]example.com doesn't. Those traps are very hard to find and avoid even with a ton of info from the trap owner - like SC.
  4. Wouldn't work because all personal mail would be forwarded. Basically the same solution as having someone else simply check your mailbox for important mails. Reading other peoples personal mail is actually illegal in many places. Unfortunately many customers have a notion that they're the only customer and that everybody personally is working 24/7 without breaks, sleep etc. - yes, I've awoken to a mailbox featuring a series of mails from the same customer that starts out with a support request and 15 mails and 4 hours later ending the threats about lawsuits etc. Now, one thing is our own website - we could easily put it there, but we're also a hosting business and we have many customers with their own servers and websites and it's hard to explain to them how they should be doing business. This is the core issue - we are responsible for the connectivity but have zero influence on how our customers do business as long as they don't spam or spamvertise. We do filter away spam before *our* auto-responders, and they only very rarely fall prey to responding to spam, but our customers have their own mailservers and thus their own auto-responders. Their responses come out through our gateways and thus it's our gateways that get listed. The reason we enforce this gateway setup is the virus plague. We need to prevent infected machines (most of which are not under our control - they belong to customers) from drowning each other and the world in emails. Thus the simple idea that machines internally can only reach the gateway on port 25, not each other or the world. About filtering auto-responses... Trouble is that the response itself does not contain the spam itself. It is simply a response with a unique recipient. No way to tell what it responded to. There are already loop control measures in place to prevent primitive auto-responders from responding to each other in a loop, so any given recipient can only receive one auto-response an hour from any given account. For an extended abusing spam run this still yields 24 auto-responses per 24 hours and thus a SC listing. I would love to know how people in the hosting business like we are do manage this. Setting rules inside the same company is just a matter of deciding them and enforcing them. Doing the same across completely separate and unrelated companies are next to impossible, especially since the so-called dangers of auto-responses just doesn't seem to strike any form of sympathy. I know that a lot of people just cannot see what harm an auto-response you didn't ask for can do. Only if they're flooding your mailbox is it a problem, but a single one is nothing to get all worked up about.
  5. 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.
  • Create New...