Jump to content

Too much wasted time for a non-help query


ClayRabbit

Recommended Posts

Moderator Edit: Enough is enough ... Another "new post and the continuing converstaion had already been merged into an existing conversation that this user had joined into with this post. After the continuing saga of "don't understand" ... "don't care to figure it out" ... etc. .... this flow of stuff from this pont has been split out of http://forum.spamcop.net/forums/index.php?showtopic=3510 .. made into its own Topic .. and moved to the Lounge as the rant that it is ....

You are say 'What used to be a courtesy, now is abuse'. Where is that defined?
In the real world.

Heh... It's quite common for blocklists to fall into megalomania sooner or later.

Yes, bounces is a problem. But your "solution": "the thousands ISP's over the world is a morons, so let's kick them off" - that's wrong way.

I'm never used any "political" blocklists, only technical (such as open relays/proxies and DUNs) blocklists because they quite independent from human's ambitions.

I'll continue to use spamcop as spam reporting tool, but I'll never use it's bl.

Just my opinion.

Link to comment
Share on other sites

Heh... It's quite common for blocklists to fall into megalomania sooner or later.

Yes, bounces is a problem. But your "solution": "the thousands ISP's over the world is a morons, so let's kick them off" - that's wrong way.

You misunderstand the (recommended) use of the SpamCopDNSBL.

I'm never used any "political" blocklists, only technical (such as open relays/proxies and DUNs) blocklists because they quite independent from human's ambitions.

Where do you find anything "political" in the process?

I'll continue to use spamcop as spam reporting tool, but I'll never use it's bl.

Just my opinion.

And in my opinion, this post is quite a turn-around from your previous three ... those complaining that not enough reporting was going on ...????

Link to comment
Share on other sites

  • 1 year later...

I'm so happy to se IP's of our servers in blacklist again.

Doesn't matter that we have requested reports for our networks. SpamCop doesn't provide any info. Just because of "spam traps are secret, no reports or evidence are provided by SpamCop", we'll just blacklist you without any explanation and f*ck off.

So what I should do? We have few hundreds accounts on each shared hosting server (but for most of them SMTP-usage is limited to 500 recipients per day by default), and there is no way to determine the source of problem because I even didn't see offending message.

So, the only way is just switch IP for mailserver, and go as before.

Thanks SpamCop, you REALLY helps to fight with spam and spammers that way!

As we see anybody can be listed without any explanation, so what's the difference from spamhaus, fiveten, blars and other idiotic political blacklists?

Moderator Edit: due to the "political blacklist" reference, this "new" post (andfollowing discussion) is being merged into another existing Topic .. in which this term came up by the same user, questions were asked, and no response offered ... PM sent to advise on the Move/Merge

Link to comment
Share on other sites

I'm so happy to se IP's of our servers in blacklist again. Doesn't matter that we have requested reports for our networks. ...[snip]

So, the only way is just switch IP for mailserver, and go as before.

Have you tried reading the FAQ entries? You'll have seen that you can get details of spamtrap related reports by contacting deputies[at]spamcop.net

Changing IP address won't help at all unless the spam stops. If spam continues from the new IP then that address will be listed.

One of the common causes of spamtrap listings is the use of auto-responders and misdirected bounces. You might try the FAQ for more information.

Meanwhile, please note that these forums are users helping other users. Whilst your frustration is obvious, off loading it on other users isn't very useful since we're just trying to be helpful here. Swearing at us doesn't typically make anyone more inclined to offer voluntary help.

Andrew

Link to comment
Share on other sites

83.102.212.34

83.102.151.66

Sorry for my rudeness, but I'm just trying to say that spamcop listing becomes too aggressive in my opinion. You never know when you shared-hosting server get blacklisted with those brainless "spamtraps".

Link to comment
Share on other sites

83.102.212.34

83.102.151.66

Sorry for my rudeness, but I'm just trying to say that spamcop listing becomes too aggressive in my opinion. You never know when you shared-hosting server get blacklisted with those brainless "spamtraps".

OK I've checked and you are quite correct, both of these servers are listed due only to spamtrap hits.

By definition ALL mail received by these secret addresses is unsolicited (a.k.a spam) so something is definitely wrong with your configuration. You can email deputies[at]spamcop.net to ask (nicely!) what type of stuff is hitting the traps. Don't expect a quick reply if you go to them with the same attitude you came here with.

Yes, spamcop is aggressive and reacts quickly to both list and de-list. That's why it's NOT recommended as a blocking tool. It also acts as a quick 'heads-up' to responsible admins to fix the problem. If you don't you may end up on lists that are a lot more difficult to get off.

Link to comment
Share on other sites

so something is definitely wrong with your configuration
Do you understand what shared-hosting means? Hundreds of users on one server. One user's PC got a virus? Message to spamtrap - server blacklisted. One user got an exploit in their web-scri_pt? Message to spamtrap - server blacklisted. And, damn, yes we are using exim MTA with it's "delayed bounces"...

So we are defenitely bad guys with wrong configuration, yeah?

It's OK when it's regular report - we are able to determine problem and react before got banlisted, but spamtraps it's just silent meanness.

Link to comment
Share on other sites

Do you understand what shared-hosting means? Hundreds of users on one server. One user's PC got a virus? Message to spamtrap - server blacklisted. One user got an exploit in their web-scri_pt? Message to spamtrap - server blacklisted. And, damn, yes we are using exim MTA with it's "delayed bounces"...

So we are defenitely bad guys with wrong configuration, yeah?

It's OK when it's regular report - we are able to determine problem and react before got banlisted, but spamtraps it's just silent meanness.

For every spamtrap hit there are probably thousands of messages being sent to innocent parties because their email address is in the forged return envelope. I am currently having to deal with 50 or more per day to my wife's account. Every one of them is reported as spam. Others have had thousands a day making their accounts unusable so yes, you definitely have the wrong configuration. Fix it or face the consequences.

Link to comment
Share on other sites

"exim MTA = wrong configuration"

Of course you are RIGHT without doubt! Everyone who still using exim MTA should be punished!

I am currently having to deal with 50 or more per day to my wife's account.
Oh... I wondering why even SpamCop still not saved you from that nightmare?...
Link to comment
Share on other sites

"exim MTA = wrong configuration"

Of course you are RIGHT without doubt! Everyone who still using exim MTA should be punished!

I'm glad you agree. Wrong for 21st century, anyway - spammers have spoiled for everyone. But it's not MY server that's listed so have it your own way, I'm out of here.

Link to comment
Share on other sites

Of course it's better to blame the whole word, and demand providers to drop their MTA, than to setup a small simple filter for deletion messages with empty Return-Path (if you hates bounces so ;) You even don't need SpamCop for that, you know?

Link to comment
Share on other sites

Hmm, I suppose you could do that, but then you would be running a non-RFC compliant mail server as the RFCs require that mail servers accept messages with an empty return-path. You're far better to reject with a 500 series error message during the SMTP transaction than to accept a message and bounce it after the fact. For one thing, it saves YOUR bandwidth, as you reject immediately after RCTP TO rather than waiting for the whole message to be received and deciding if the user really exists or is over quota.

If your MTA is not capable of rejecting with a 500 series SMTP error, then I would strongly suggest turning bounces off altogether. My record is over 1000 bounces received in a single day. Now, thanks to spamcop, spamhaus, and a few filters, I haven't seen a misdirected bounce in weeks. My server, my rules, I don't accept email from improperly configured mail servers that spew spam to every corner of the world.

Link to comment
Share on other sites

My server, my rules, I don't accept email
So why you talking about RFC, right?

"RFCs require that mail servers accept messages with an empty return-path" but you and SpamCop considering those messages as spam and don't want it anyway. Moreover instad of just disabling remote bounces receiveing you prefer to "punish" providers that sends bounces (and their customers) by rejecting all mail from them completely.

Link to comment
Share on other sites

Do you understand what shared-hosting means? Hundreds of users on one server. One user's PC got a virus? Message to spamtrap - server blacklisted. One user got an exploit in their web-scri_pt? Message to spamtrap - server blacklisted. And, damn, yes we are using exim MTA with it's "delayed bounces"...

So we are defenitely bad guys with wrong configuration, yeah?

It's OK when it's regular report - we are able to determine problem and react before got banlisted, but spamtraps it's just silent meanness.

Again blame the spammers. spam traps hits don't generate reports because, I believe, of the fact that to be a true spam trap, it doesn't send email. It might also give a heads up to the spammers.

Other server admins are able to detect viruses, exploits in web-scripts, etc. by keeping a careful watch on their logs, I believe (I am not sure whether you are complaining about your users or whether that's what you think causes the spam trap hits). I am not a server admin so I don't know how they do it, but I do know that other server admins have been able to adjust to this new problem caused by spammers.

Spamcop serves as an early warning system for admins. If you ignore the spamcop listing, then chances are that you will end up on some other blocklist because of spam trap hits.

Unsolicited email is unsolicited email. If I didn't send the message, then I don't want to know that it wasn't delivered.

Miss Betsy

Link to comment
Share on other sites

83.102.212.34

83.102.151.66

Sorry for my rudeness, but I'm just trying to say that spamcop listing becomes too aggressive in my opinion. You never know when you shared-hosting server get blacklisted with those brainless "spamtraps".

Well, looking at the SenderBase page at http://www.senderbase.org/search?searchString=83.102.151.66 .. one would have to say that as a "political blacklist" intended to "block all your e-mail" ... the SpamCopDNSBL is doing a terrible job. Only two of your servers out of the 10 possiblilities identified ...???

Do you understand what shared-hosting means? Hundreds of users on one server. One user's PC got a virus? Message to spamtrap - server blacklisted. One user got an exploit in their web-scri_pt? Message to spamtrap - server blacklisted. And, damn, yes we are using exim MTA with it's "delayed bounces"...

So we are defenitely bad guys with wrong configuration, yeah?

You slip from a configuration issue to a a 'control of server output' problem ... but both matters would end up being the same person's responsibility in the end. And as referenced a but further on .... there is a bit of a math formula involved .... your "shared host with hundreds of users" are a factor in that formula.

It's OK when it's regular report - we are able to determine problem and react before got banlisted, but spamtraps it's just silent meanness.

The SpamCop FAQ here has a link titled "What is on the list?" .... perhaps a read through that might explain the "meanness" involved ... you should note that there is a distinct lack of "where is the IP address in the world" factoring involved.

So why you talking about RFC, right?

"RFCs require that mail servers accept messages with an empty return-path" but you and SpamCop considering those messages as spam and don't want it anyway. Moreover instad of just disabling remote bounces receiveing you prefer to "punish" providers that sends bounces (and their customers) by rejecting all mail from them completely.

No idea how that rambling could end up with "SpamCop.net rejecting all e-mail from them completely" .... your shared-hosting users "send" some e-mail. Some of that e-mail reaches an ISP that has chosen to use the SpamCopDNSBL in a blocking fashion. Yet for every one ISP using the SpamCopDNSBL in this (not recommended) way, there are probably thousands of other ISPs arouund the world that either use the SpamCopDNSBL in a tagging/managing fashion, or don't use it all .... and even at that, the time of listing is based on your getting control and resolving the problem ...

Link to comment
Share on other sites

If you come up with it, please share. The world is waiting for that better solution.
You have asked for another solution? I described it above. Anyone who able to setup rbl-checking, is also able to setup simple filter to blackhole all remote bounces.

And any normal correspondence wouldn't be affected unlike when you are using spamcop rbl as protection from misdirected bounces.

Unfortunamely, AFAIK, many admins using RBLs thoughtlessly. They just paste 1-3 rbls in config, and though - now it's all right with my mail. I think many of them is not quite aware that using SpamCop RBL for mail rejection currently means "I agree to reject all mail from any mailserver just because that server supports autoresponders & vacation messages and/or running postfix or exim". At least most of postfix and exim users wouldn't use bl.spamcop.net if they realized that fact, I think :)

Link to comment
Share on other sites

Unfortunamely, AFAIK, many admins using RBLs thoughtlessly. They just paste 1-3 rbls in config,

and???? Again, this is up to that ISP.

I think many of them is not quite aware that using SpamCop RBL for mail rejection currently means "I agree to reject all mail from any mailserver just because that server supports autoresponders & vacation messages and/or running postfix or exim". At least most of postfix and exim users wouldn't use bl.spamcop.net if they realized that fact, I think :)

I don't see anywhere that this information is posted .... I suggested a link to What is on the list? .. yet you still male a statement like this? And then toss in a couple of e-mail server software packages in a reference to using a BL ...???? not sure I see your connection at all ... use of a BL is dealing with the incoming, your listing issue seems to deal with outgoing, and your/any e-mail application is in between, thusly taking one back to a configuration and execution issue of that software.

Link to comment
Share on other sites

I don't know about Exim, but any even remotely current version of Postfix is capable of rejecting during the SMTP phase with a 500 series error. Thats strictly a configuration issue. And yes, I do understand what rejecting email using an RBL means, and I have options in place if it causes a problem. If someone that we need to correspond with ends up on one of the BLs we use, I simply whitelist their email address or server as needed, not really a big deal.

Link to comment
Share on other sites

Currently I didn't found any Exim configuration examples for disabling bounces completely. Mostly bounces generated when mailbox is over quota, but all quota checks are made inside 'transports' which is running _after_ SMTP session is closed.

Sorry Wazoo, I don't understand most of your posts. Maybe because of my bad english it feels like you saying nothing concrete... It seems we just don't understand each other.

Do you agreee that using SpamCop RBL for mail rejection currently means "I agree to reject all mail from any mailserver just because that server supports autoresponders & vacation messages and/or running MTA with delayed bounces"? That's a fact, isn't it?

Link to comment
Share on other sites

Sorry Wazoo, I don't understand most of your posts. Maybe because of my bad english it feels like you saying nothing concrete... It seems we just don't understand each other.

Do you agreee that using SpamCop RBL for mail rejection currently means "I agree to reject all mail from any mailserver just because that server supports autoresponders & vacation messages and/or running MTA with delayed bounces"? That's a fact, isn't it?

No, I don't agree.

No, it is not a fact.

Link to comment
Share on other sites

I agree to reject all mail from any mailserver just because that server supports autoresponders & vacation messages and/or running MTA with delayed bounces"

Wazoo says that statement is not correct. I am not a server admin so I don't know the technical reasons why that is not correct. However, there may be ways that you can capture the spam so that the autoresponders & vacation messages and delayed bounces only respond to legitimate messages. The server would get on the spamcop bl ONLY if it sent messages to spam traps or many messages to more than one reporter.

From what I understand of server admins' discussions, it is much easier to turn those things off or use alternate methods. Telarin mentioned whitelisting. However, as long as whitelisting is used then server admins such as yourself will continue to spew spam (unsolicited email) because their customers won't complain or leave.

IOW, autoresponders, vacation messages, and delayed bounces are very good ideas that the spammers have spoiled. Even spamcop admin argued against having them reported until it was evident that those kinds of messages had become really annoying and disabling. Other server admins have adapted to the new environment.

Miss Betsy

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...