Jump to content
Sign in to follow this  
Bojan

What can we do regarding blocking?

Recommended Posts

Hi,

Recently I had 2 of my e-mail servers (from a cluster of 4) blocked in SpamCop.

Those servers are the main mail gateway for our University, and we are pretty strict in blocking outgoing port 25 for all other machines - they have to send e-mail through the gateway, which scans for viruses in outgoing e-mails.

Now, on SpamCop's webpage, the reason for being blacklisted is that someone sent e-mail to SpamCop's spam trap addresses.

This gateway processes about 500.000 e-mails per day. As SpamCop's spam trap addresses are secret, I can't even trace users who did this.

So what can I do here? Listing in SpamCop caused e-mails to be rejected from other hosts.

The whole idea with spam traps is nice, but in my case (and probably for other gateways) it's a bit stupid - we pay the price because someone sent e-mails to them, and we can't even find out who.

Any comments on this?

Share this post


Link to post
Share on other sites
Any comments on this?

37686[/snapback]

Nothing that is not already explained in the FAQ. Unless you missed something?

Share this post


Link to post
Share on other sites
Now, on SpamCop's webpage, the reason for being blacklisted is that someone sent e-mail to SpamCop's spam trap addresses.

This gateway processes about 500.000 e-mails per day. As SpamCop's spam trap addresses are secret, I can't even trace users who did this.

So what can I do here? Listing in SpamCop caused e-mails to be rejected from other hosts.

37686[/snapback]

Spamcop uses a percentage of spam/valid traffic to determine listing status. One report (I don't think even a trap report) will not cause a listing.

To get SOME additional information, send an email to deputies[at]spamcop.net with enough information to show you are responsible for administering that server.

Share this post


Link to post
Share on other sites
Spamcop uses a percentage of spam/valid traffic to determine listing status.  One report (I don't think even a trap report) will not cause a listing.

To get SOME additional information, send an email to deputies[at]spamcop.net with enough information to show you are responsible for administering that server.

37688[/snapback]

Thanks Steven - I'll contact them to see what I can do - I definitely don't want my servers being listed in SpamCop.

One other problem we have is with NDN bounces. For couple of most used servers (student server, the official staff server) we implemented virtual domains at the front end, so it will properly reject e-mails.

However, there are multiple internal servers in various faculties and departments that we have no control of, and we have to relay for them (so we can at least do AV scans, and spam scan). They result in NDN bounces as well - if I could I would stop that immediately, but it's up to the politics.

Lastly, e-mail from SpamCop has some bad delays (IronGate problems?). I clicked on the delist link and it took 50 minutes to deliver the e-mail. From the headers it's visible that the delay happened from SpamCops server ... maybe it would be good to either check this (if someone from SpamCop is reading this), or to have another means for admins - I had to wait 50 minutes to delist the server, and it's peak time for users here :(

Thanks again for your reply.

Cheers,

Bojan

Share this post


Link to post
Share on other sites
One other problem we have is with NDN bounces. For couple of most used servers (student server, the official staff server) we implemented virtual domains at the front end, so it will properly reject e-mails.

However, there are multiple internal servers in various faculties and departments that we have no control of, and we have to relay for them (so we can at least do AV scans, and spam scan). They result in NDN bounces as well - if I could I would stop that immediately, but it's up to the politics.

37692[/snapback]

Most mail packages support this kind of configuration with no problems. Of course, without knowing what you are running, it is impossible to say for sure. Exchange using Active Directory should be aware of all recipients in the forest, so should know what to accept and reject based on validity of the recipient. If you do effective spam filtering at the front end, and at least make sure recipients are valid, then it is unlikely that enough forged mail will get through to get you listed from things like full mailboxes and OORs.

You could also configure the back-end servers to not send NDRs at all.

Share this post


Link to post
Share on other sites
Most mail packages support this kind of configuration with no problems. Of course, without knowing what you are running, it is impossible to say for sure. Exchange using Active Directory should be aware of all recipients in the forest, so should know what to accept and reject based on validity of the recipient. If you do effective spam filtering at the front end, and at least make sure recipients are valid, then it is unlikely that enough forged mail will get through to get you listed from things like full mailboxes and OORs.

You could also configure the back-end servers to not send NDRs at all.

37696[/snapback]

Yeah - technically this is not a problem (we use postfix here, can implement almost anything with it). However, the problem is more of a political nature that I wouldn't go into.

Let's just say I'm pushing this .. but where to, who knows.

Share this post


Link to post
Share on other sites
Lastly, e-mail from SpamCop has some bad delays (IronGate problems?). I clicked on the delist link and it took 50 minutes to deliver the e-mail. From the headers it's visible that the delay happened from SpamCops server ... maybe it would be good to either check this (if someone from SpamCop is reading this), or to have another means for admins - I had to wait 50 minutes to delist the server, and it's peak time for users here :(

37692[/snapback]

That would be another point to mention to the deputies. (Most) everyone here is simply a happy user of the systems provided by spamcop.

Also, it is not wise to delist without fixing the problem that caused the listing because that is a one time only option.

Share this post


Link to post
Share on other sites
That would be another point to mention to the deputies.  (Most) everyone here is simply a happy user of the systems provided by spamcop.

Also, it is not wise to delist without fixing the problem that caused the listing because that is a one time only option.

37700[/snapback]

Another of our servers got listed in SpamCop today. The reason is again (pasted from the web page):

Causes of listing

System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop)

Of course, noone from SpamCop replied, either from the deputies address which Steven posted or from the Dispute form ...

SpamCop is great when it works ok for you :( but otherwise ....

Share this post


Link to post
Share on other sites
<snip>

Of course, noone from SpamCop replied, either from the deputies address which Steven posted or from the Dispute form ...

SpamCop is great when it works ok for you :( but otherwise ....

37814[/snapback]

...Sometimes the Deputies get backlogged and it takes them a little while to catch up on their e-mail. I would urge you to give them about 48 hours and if still no reply, send a follow-up. If you don't hear within 48 hours after that, one of us can try for you in case for some reason your e-mail is not getting through. You can "PM" me if you wish with a request to do that, although some of the other senior members here seem to have a slightly closer relationship with the SpamCop powers that be (any volunteers?). Thanks, Bojan!

Share this post


Link to post
Share on other sites
...Sometimes the Deputies get backlogged and it takes them a little while to catch up on their e-mail. I would urge you to give them about 48 hours and if still no reply, send a follow-up. If you don't hear within 48 hours after that, one of us can try for you in case for some reason your e-mail is not getting through. You can "PM" me if you wish with a request to do that, although some of the other senior members here seem to have a slightly closer relationship with the SpamCop powers that be (any volunteers?). Thanks, Bojan!

37816[/snapback]

Thanks a lot Steve. I'll wait for a bit more and then will let you know.

It wouldn't be a big problem really, but seems like there are a lot of sites which reject e-mail based on SpamCop (we use SpamCop as well, but only as a rule in SpamAssassin, so it will give certain score to the final result).

Those rejected e-mails made number of calls received by our Service Desk go pretty high and soon we'll have to issue something "official" to them. If it was something I could fix myself I'd do it immediately, but as it's spam traps which are causing our server(s) to be blacklisted, there's nothing I can do.

Thanks again for your reply.

Share this post


Link to post
Share on other sites

Hi Bojan

It sounds as if you are at a college. When you are trying to convince these other departments to configure their computers to not send NDNs (or auto replies), you might try an analogy with recycling. It takes a little extra to be aware of environmental concerns and to sort one's trash, but it is worthwhile for the whole environment. And having everyone participate makes a big difference. One person who litters makes it nasty for everyone else. It is the same with spam.

And for spam to be controlled, the *sending* end needs to be aware and responsible.

Academics might understand why it is important to do what you need to do to stay off the blocklists if you compare it with something they know and support.

Another point is that the scbl is an early warning system because it is so aggressive. If you don't get the problem fixed, then other lists will begin to list you.

Although using spamcop as part of one's filtering is probably the best way to use it, nevertheless it is working the way it is supposed to. 'Backscatter' has become a major problem for many people who are sometimes overwhelmed by NDNs to forged addresses.

HTH with the 'politics' side of your problem

Miss Betsy

Share this post


Link to post
Share on other sites
...Sometimes the Deputies get backlogged and it takes them a little while to catch up on their e-mail. I would urge you to give them about 48 hours and if still no reply, send a follow-up. If you don't hear within 48 hours after that, one of us can try for you in case for some reason your e-mail is not getting through. You can "PM" me if you wish with a request to do that, although some of the other senior members here seem to have a slightly closer relationship with the SpamCop powers that be (any volunteers?). Thanks, Bojan!

37816[/snapback]

Thanks a lot Steve. I'll wait for a bit more and then will let you know.

<snip>

37818[/snapback]

...Bojan, have you received a reply yet? If not, please be aware that one of the deputies has sent a private communication to one of the other "senior" Forum participants (in reply to his communication on another topic) indicating that the deputies are seriously backlogged due to new spammer tricks and the latest virus outbreak. So please have patience. I'm sure I speak for them when I say I'm sorry for the inconvenience.

Share this post


Link to post
Share on other sites
Thanks a lot Steve. I'll wait for a bit more and then will let you know.

<snip>

37818[/snapback]

...Bojan, have you received a reply yet? If not, please be aware that one of the deputies has sent a private communication to one of the other "senior" Forum participants (in reply to his communication on another topic) indicating that the deputies are seriously backlogged due to new spammer tricks and the latest virus outbreak. So please have patience. I'm sure I speak for them when I say I'm sorry for the inconvenience.

37899[/snapback]

Yeah, I haven't received any reply back so far.

I just sent another e-mail (lets call it a reminder :) .. Hope I'll get some reply soon.

Cheers,

Bojan

Edit: Jeff G. fixed the quoting.

Edited by Jeff G.

Share this post


Link to post
Share on other sites
Yeah, I haven't received any reply back so far.

I just sent another e-mail (lets call it a reminder :) .. Hope I'll get some reply soon.

Cheers,

Bojan

Edit: Jeff G. fixed the quoting.

38029[/snapback]

And 14 days after the initial e-mail no reply back. In total I sent 3 e-mails and used the web form twice, absolutely nothing came back.

Today our system got blacklisted again: http://www.spamcop.net/w3m?action=checkblo...=130.216.190.11

The only cause listed is that it sent e-mails to spam traps. Sure, it's a gateway for 6000+ other machines.

I understand that the deputies can be flooded with e-mails, but the fact that noone replied for 14 days (not even with: yes, we received your e-mail, but we are flooded so please wait) - I'm not counting people that posted here (thanks to whoever helped so far).

Really disappointed, not to mention new calls that are waiting our service desk.

Bojan

Share this post


Link to post
Share on other sites
... Really disappointed, not to mention new calls that are waiting our service desk.

38437[/snapback]

Lack of response certainly is "disappointing", also detrimental to the fight against spam. CBL has been carrying the following notice for a month,
A recent Sober worm variant is causing considerable havoc on the Internet. This particular variant sends out email allegedly from the FBI or CIA (amongst other things). It is known by anti-virus companies under several different names: Sober.U (eg: ClamAV), Sober.Z (eg: Sophos) and Sober.X (eg: Symantec).

This is currently one of the leading cause of CBL detections (with somewhere around 100,000 detections). People using the self-delisting page without doing any investigation whatsoever are causing the CBL web pages to operate rather slowly - to little end, because if you don't eradicate your Sober.Z infection, you're just going to get listed again.

which possibly sheds some light on the general situation (and SpamCop reportedly has yet further matters on its plate). Even a notice similar to the above would have been "something". Seems like a darned poor effort on SC's part.

Share this post


Link to post
Share on other sites

With the inclusion of your listed IP, I see only a couple of reports publically available, most being old, but there was a real report (mole status) yesterday. The oldest appears to be a bounce, but hopefully that has been taken care of. Sorry the deputies have not gotten back to you. Their suggestion to me was to keep the emails short and provide enough information so they do not need to make followup emails...those are the ones generally going to the back burners.

Providing the IP address you did here along with a statement you are responsible for it and a quick question as to what is hitting the spamtraps will hopefully get you a response.

Report History:

--------------------------------------------------------------------------------

Submitted: Sunday, December 25, 2005 9:35:30 AM -0500:

RE: ***spam*** The thing is that a great errrection is provided for you exact...

1597929667 ( 130.216.190.11 ) To: mole[at]devnull.spamcop.net

--------------------------------------------------------------------------------

Submitted: Monday, November 14, 2005 2:43:06 PM -0500:

Jerome Hi, great news

1555977031 ( 130.216.190.11 ) To: spamcop[at]imaphost.com

--------------------------------------------------------------------------------

Submitted: Tuesday, October 25, 2005 1:32:26 PM -0400:

Undelivered Mail Returned to Sender

1539376668 ( 130.216.190.11 ) To: postmaster[at]auckland.ac.nz

1539376661 ( 130.216.190.11 ) To: abuse[at]auckland.ac.nz

The following test seems to indicate you are rejecting during the SMTP transaction:

220 groucho.itss.auckland.ac.nz ESMTP The University of Auckland

helo underwood.spamcop.net

250 groucho.itss.auckland.ac.nz

mail from: <underwood+test[at]spamcop.net>

250 Ok

rcpt to: <test1234567890[at]auckland.ac.nz>

550 <test1234567890[at]auckland.ac.nz>: Recipient address rejected: User unknown in virtual alias table

quit

221 Bye

Share this post


Link to post
Share on other sites
130.216.190.11 ... it's a gateway for 6000+ other machines.

38437[/snapback]

Can you please explain what you mean by that? If it's an SMTP Relay (a smarthost for your customers), it appears (on the basis of the SpamCop Reports) that it is not properly recording the source IP Address in its Received Header Line. If it's a NAT (Network Address Translation) gateway, please configure it or your firewall to block connections to SMTP Port 25 outside your network, except for authorized SMTP Relays. Thanks!

Share this post


Link to post
Share on other sites
Providing the IP address you did here along with a statement you are responsible for it and a quick question as to what is hitting the spamtraps will hopefully get you a response.

38442[/snapback]

Thanks for your reply.

My e-mail to deputies was very similiar to what you suggested. There are actually 4 IP addresses (130.216.190.11 - .14) - 4 servers which are relays.

We properly reject main domains (auckland.ac.nz for staff and ec.auckland.ac.nz for students), but there are multiple other subdomains we have to relay for and which will improperly generate a bounce - I'm aware of this but moving forward is very slow in an academic environment.

Anyway, I'll try sending the e-mail to deputies again. The main problem this is that I need "ammunition" when approaching users. If there is a compromised machine on campus which is sending 1 e-mail every minute, I will never find it (as I said, the gateway processes ~500.000 e-mails per day).

Thanks for your reply again.

Bojan

Share this post


Link to post
Share on other sites
Can you please explain what you mean by that?  If it's an SMTP Relay (a smarthost for your customers), it appears (on the basis of the SpamCop Reports) that it is not properly recording the source IP Address in its Received Header Line.  If it's a NAT (Network Address Translation) gateway, please configure it or your firewall to block connections to SMTP Port 25 outside your network, except for authorized SMTP Relays.  Thanks!

38446[/snapback]

Hi Jeff,

It's an SMTP relay for the whole University. We block outgoing port 25 on our border firewall, and any machine that wants to send e-mails have to do it through our gateway. The gateway will do at least AV scan for outgoing e-mails.

There are 4 machines in the cluster, all under one DNS name so we have cheap man's round robin load balancing.

I built and configured those servers myself and I'm pretty sure that it's properly recording the source IP address in the received header (I would even go so far to say that I'm suspecting SpamCop Reports here). If you want, I can send you a test e-mail so you can see yourself (it's a standard postfix+amavisd-new setup).

We allow normal relay only for our class B network. Students and staff can relay through the server from anywhere, providing that they successfully authenticated before.

My main problem with SpamCop here is that the only reports I've seen have been for e-mails sent to spam traps. This means that I have nothing to investigate - I got no e-mail back, I don't know what spam traps are (and that's fine, SC operates like that) and I sure won't go through half a million e-mails per day to see what happened.

The biggest problem for me is that our users are generating service desk calls which end up on me, and there's nothing I can do about them (sure, I tell the story that the SpamCop list has nothing to do with blocking, that it's remote site's decision to block on it ... but that all means nothing to our users). And keep in mind that we're a decent size University - ~40.000 students and 6.000+ staff.

Thanks for help,

Bojan

Share this post


Link to post
Share on other sites

Providing the IP address you did here along with a statement you are responsible for it and a quick question as to what is hitting the spamtraps will hopefully get you a response.

Report History:

--------------------------------------------------------------------------------

Submitted: Sunday, December 25, 2005 9:35:30 AM -0500:

RE: ***spam*** The thing is that a great errrection is provided for you exact...

1597929667 ( 130.216.190.11 ) To: mole[at]devnull.spamcop.net

--------------------------------------------------------------------------------

Submitted: Monday, November 14, 2005 2:43:06 PM -0500:

Jerome Hi, great news

1555977031 ( 130.216.190.11 ) To: spamcop[at]imaphost.com

--------------------------------------------------------------------------------

Submitted: Tuesday, October 25, 2005 1:32:26 PM -0400:

Undelivered Mail Returned to Sender

1539376668 ( 130.216.190.11 ) To: postmaster[at]auckland.ac.nz

1539376661 ( 130.216.190.11 ) To: abuse[at]auckland.ac.nz

Btw, something else that I remembered.

This first report, from Sunday looks pretty interesting.

First, it has ***spam*** in the subject, which is what our e-mail gateway does when it receives e-mails. It does not scan outgoing e-mails for spam, so this e-mail arrived to us first and then somehow was sent to SpamCop.

Having Re: in the subject makes me believe that it was either a user on our network that replied, or some stupid filter (yes - we have users who setup their filters to catch spam marked e-mails and then, instead of discarding them or putting them in a different folder, they actually *reject* them).

This whole thing is still very very weak for me - I know you said that those are only thing publically available (there might be more that we can't see), but if those 3 e-mails in 3 months made our machine to be blacklisted, it doesn't make much sense does it?

Off to sleep now. Thanks again for useful discussion and for your good will to help.

Cheers,

Bojan

Share this post


Link to post
Share on other sites
Btw, something else that I remembered.

This first report, from Sunday looks pretty interesting.

First, it has ***spam*** in the subject, which is what our e-mail gateway does when it receives e-mails. It does not scan outgoing e-mails for spam, so this e-mail arrived to us first and then somehow was sent to SpamCop.

Having Re: in the subject makes me believe that it was either a user on our network that replied, or some stupid filter (yes - we have users who setup their filters to catch spam marked e-mails and then, instead of discarding them or putting them in a different folder, they actually *reject* them).

Bojan

38458[/snapback]

Then you will almost certainly continue to be listed! There is no excuse in 2005 for allowing your users to abuse the internet in this way. See the FAQ on backscatter and auto-responders. ISTM that your biggest problem is spamtrap hits. SpamTraps are secret non-guessable e-mail addresses that have NEVER sent mail and therefore can not possibly have asked for any. Thety are hidden in the code of web-sites where spammers bots harvest them. Any mail sent to them is by definition unsolicited and these hits count much more in the maths for listing. You really need to take more control and be more responsible about what is going out through your servers.

Edited PS: Oh, and what you describe is not *rejecting*: that needs to be done with a 5** code during the SMTP transaction. What they are doing is abusing innocent victims whose addresses have been spoofed in the return envelope. If you want to stay off the lists YOU must stop this.

Edited by Derek T

Share this post


Link to post
Share on other sites
Then you will almost certainly continue to be listed! There is no excuse in 2005 for allowing your users to abuse the internet in this way. See the FAQ on backscatter and auto-responders. ISTM that your biggest problem is spamtrap hits. SpamTraps are secret non-guessable e-mail addresses that have NEVER sent mail and therefore can not possibly have asked for any. Thety are hidden in the code of web-sites where spammers bots harvest them. Any mail sent to them is by definition unsolicited and these hits count much more in the maths for listing. You really need to take more control and be more responsible about what is going out through your servers.

Edited PS: Oh, and what you describe is not *rejecting*: that needs to be done with a 5** code during the SMTP transaction. What they are doing is abusing innocent victims whose addresses have been spoofed in the return envelope. If you want to stay off the lists YOU must stop this.

38459[/snapback]

You can always pick out the replies from someone that doesn't run a mailserver. 500,000 emails a day is a lot of email to police, no matter how big your staff, and how good your software.

If I understand you right, the problem sounds like it may be your users sending auto-replies to spam messages. In a small organization, that is pretty simple to take care of, but in an organization your size, its going to be nearly impossible to police manually.

First, as was stated before, I would make absolutely certain that your servers are preserving the IP address from which the message originates in the headers. However, even doing this, the relay's IP will likely also get reported when something hits a spam trap, so that will really only help you if you can get ahold of the deputies.

Are IPs being assigned dynamically or statically in your network? If they are dynamic, finding the originating computer may be difficult, though if its simply an auto-response of some kind, the "From" line of the header should be correct.

I don't know what your mailserver is capable of, but you might see if you can configure the same spam filters that mark messages as "***spam***" on the way in, to prevent messages marked with "***spam***" from being sent so at least auto replies should be dropped on their way out, and you might be able to use logs from that to check the offending users.

The users causing the biggest problems should be obvious as they will likely be sending far more messages than regular users (since most of them will be auto-responses). You might be able to check server logs for accounts sending higher than normal volumes of email.

I can appreciate your problem, as you seem to be stuck between the slow moving machinery that makes up the politics of a large university, and the quick moving machinery of the internet. Not a good place to be by any means.

You might want to contact the destination ISPs that are generating the most help desk calls, and try to get them to whitelist your outgoing servers temporarily until a more permanent solution can be found and put into place. At least that may reduce the noise from the squeekiest wheels so to speak.

I would imagine that the solution is going to be 25% technological, and 75% political. If you can get some kind of Acceptable Use Policy in effect that makes this type of behavior unacceptable, then at least you can start removing mail priveledges from the users that are causing the problems until a more permanent solution can be found.

At this point, I suppose your biggest issue is simply going to be to keep trying to get in touch with the deputies so you can find out which of your users are causing the immediate problem, and get that taken care of first. From there, some AUP changes, and enforcement of those changes, should help prevent future problems.

Share this post


Link to post
Share on other sites
Then you will almost certainly continue to be listed! There is no excuse in 2005 for allowing your users to abuse the internet in this way. See the FAQ on backscatter and auto-responders. ISTM that your biggest problem is spamtrap hits.

Hi Derek,

Please see reply below from Telarin where he nicely put it out.

I know that there is no excuse for users, but increasing awareness of 46.000 users is very very difficult, and very very slow.

From public reports my server sent 3 (three) e-mails to spam traps. In my opinion, that's not enough to blacklist someone (sure, there might be things that I don't know of yet).

SpamTraps are secret non-guessable e-mail addresses that have NEVER sent mail and therefore can not possibly have asked for any. Thety are hidden in the code of web-sites where spammers bots harvest them. Any mail sent to them is by definition unsolicited and these hits count much more in the maths for listing. You really need to take more control and be more responsible about what is going out through your servers.

Again, it's a very very slow process. We aren't the biggest University in the world, but we have a lot of users and our gateways process a lot of e-mails - it's very difficult to police that (as Telarin nicely said).

Now that you nicely said that I have to "take more control and be more responsible about what is going out through [my] server", do you care to say how? I don't have a server for 10 people that I can control. My servers process, as I said, 500.000+ e-mails per day (sometimes can go to a million). How do I take more control over that, except by increasing user awareness (which is not technical).

Edited PS: Oh, and what you describe is not *rejecting*: that needs to be done with a 5** code during the SMTP transaction. What they are doing is abusing innocent victims whose addresses have been spoofed in the return envelope. If you want to stay off the lists YOU must stop this.

Sorry, I wasn't completely clear here. I didn't mean rejecting during the SMTP session (which is a 5** code as you said), I meant rejecting with a filter based mechanism such as Sieve.

Sieve can discard or reject a message. Yes, I know and completely agree that rejection is stupid and makes no sense. Again, it's difficult to explain that to users (I might go through our mailbox servers to see if I can disable Sieve reject).

I'm really not in a nice situation here. Don't get me wrong, I like SC and I support it, but I think that, at least in my case, it's over zealous.

I also think that we're doing much better comparing to other Universities, and think it's not fair towards us to be on the blacklist that easy.

Bojan

Share this post


Link to post
Share on other sites
I'm really not in a nice situation here. Don't get me wrong, I like SC and I support it, but I think that, at least in my case, it's over zealous.

I also think that we're doing much better comparing to other Universities, and think it's not fair towards us to be on the blacklist that easy.

38508[/snapback]

The way I understand it, unless your gateway server is not listing where it got it's message from in a way that spamcop can parse, the spamtrap hits are directly from your server machines rather than messages being routed through that server.

You can use the address in my sig to send a test or 2, one from your server and at least one routed through the server so I can try to parse it. If you do this, please indicate spamcop test in the subject line so I won't accidentally report these test messages.

Share this post


Link to post
Share on other sites
You can always pick out the replies from someone that doesn't run a mailserver. 500,000 emails a day is a lot of email to police, no matter how big your staff, and how good your software.

Hi Will,

First of all, thanks for understanding my position here (some other people seem to have problems with this).

If I understand you right, the problem sounds like it may be your users sending auto-replies to spam messages. In a small organization, that is pretty simple to take care of, but in an organization your size, its going to be nearly impossible to police manually.

That seems to be only a part of the problem. I just noticed that in one message that was pasted in a previous post, because it had ***spam*** in the subject field, and that's what our gateway does when it detects a spam message.

First, as was stated before, I would make absolutely certain that your servers are preserving the IP address from which the message originates in the headers. However, even doing this, the relay's IP will likely also get reported when something hits a spam trap, so that will really only help you if you can get ahold of the deputies.

Yes, I went again through are received headers and they are completely 100% according to RFC 822. If SC can't parse that properly, SC is broken whatever you say.

That being said, I'm sure SC parses them ok, but doesn't trust anything except the latest hop, which will be our gateway, of course (as you said as well).

I agree that only thing that can help me if I can get ahold of the deputies - nothing happened there though (16 days w/out a reply now from the first e-mail I sent).

Are IPs being assigned dynamically or statically in your network? If they are dynamic, finding the originating computer may be difficult, though if its simply an auto-response of some kind, the "From" line of the header should be correct.

Both - however, we have pretty good internal controls so, if I knew the IP address of the machine which sent the e-mail, I could trace the owner. But, w/out knowing the destination e-mail address, I can't go through the logs to find who sent it.

I don't know what your mailserver is capable of, but you might see if you can configure the same spam filters that mark messages as "***spam***" on the way in, to prevent messages marked with "***spam***" from being sent so at least auto replies should be dropped on their way out, and you might be able to use logs from that to check the offending users.

Technically I can do this without any problem. But, politically, this has to be approved first. And getting approval for dropping something at the gateway because it had something in the header is *very*, *very* difficult.

I can appreciate your problem, as you seem to be stuck between the slow moving machinery that makes up the politics of a large university, and the quick moving machinery of the internet. Not a good place to be by any means.

You might want to contact the destination ISPs that are generating the most help desk calls, and try to get them to whitelist your outgoing servers temporarily until a more permanent solution can be found and put into place. At least that may reduce the noise from the squeekiest wheels so to speak.

Thanks, I appreciate that someone understands my problem.

I will probably try to contact the destination ISPs, at first those local here in NZ, as it seems that majority of e-mails will go there.

I would imagine that the solution is going to be 25% technological, and 75% political. If you can get some kind of Acceptable Use Policy in effect that makes this type of behavior unacceptable, then at least you can start removing mail priveledges from the users that are causing the problems until a more permanent solution can be found.

At this point, I suppose your biggest issue is simply going to be to keep trying to get in touch with the deputies so you can find out which of your users are causing the immediate problem, and get that taken care of first. From there, some AUP changes, and enforcement of those changes, should help prevent future problems.

I completely agree. And this all will take a lot of time and effort.

The problem that I have hanging is that my servers are being blacklisted. And I can't do anything about it. :(

Bojan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×