UCEPROTECT does nothing wrong

Hi,

i am a mailadmin, blocking your mail via uce-protect.

You get banned because of sending automated mails back to Incoming mails from unknown addresses.

Why is this so bad?
Example:
Spammer fakes ‘from’ to be victim@victimdomain.tld and sends out 30 million emails with that forged sender, what do you think will happen?
yourcompany.tld has a properly configured mail server, the SMTP dialog will look like this:

HELO forged.domain.name
MAIL FROM: victim@victimdomain.tld
RCPT TO: NoSuchUser@yourcompany.tld
550 User unknown

In this case, the spammers will not get their crap out of their mail queue and nobody will be hurt by your server.

But, if yourcompany.tld doesn’t have a properly configured server, it will accept the email for delivery and then it will be unable to deliver the email to local user "NoSuchUser".

Your server will next return the email to the forged sender, victim@victimdomain.tld, which is logically a case of abuse, because victim@victimdomain did not send the crap to you ...

Worst case scenario: There are millions of poorly configured email servers out there, so therefore victim@victimdomain.tld will get millions of reports telling him that his email was not delivered .... What email ??? he didn’t send it ... !!

What this means to you:

If any spammer was to fake a ‘From’ to be the same as one of our spamtrap email addresses, the resulting NDR from your server would hit our spamtrap causing your IP address to be blacklisted here, because your system sends backscatter to our spamtraps.

Source: http://www.backscatterer.org/index.php?target=backscatter

So, please stop backscatter and / or sender callouts, and you will see, no more blacklisting

I am afraid you did not quite understand what the article explained. Please read again the section "Auto-replying to spam trap messages".

This site does not reply to messages sent to nonexistent addresses. However the site needs to reply to users that send messages to addresses used to unsubscribe from our newsletters, for instance.

Unfortunately many users send messages to those auto-reply addresses with addresses different from those that they used to register in the site. The site cannot ignore those messages, or else those users are not able to unsubscribe and they will report the site as spam source.

That is why UCEProtect is a bad idea. Well informed system administrators do not use it. Even more because UCEProtect is set to make money from uninformed system administrators that fall in the trap of paying the express delisting fee.

The greatest problem for system administrators that use UCEProtect is that their users may not be able to register to this site and benefit from its resources. This site automatically blacklists all domains served by mail servers that use UCEProtect. That is the way we found to stop sending messages to spam traps.

I hope you understand that this was necessary to reduce the problem of users that do not get the site messages because UCEProtect sends our site backscatterer messages to make the site be blacklisted innocently.

It is up to you to decide whether you really want to prevent your mail users from benefiting from this site as registered users.

Hi,

First: I am administrator of ~10 Mailserver with a throughput about 10.000 mails / server / day.

Lets say someone uses your private email address to send spam and everybody would configure his mailserver as you do:

The spammer sends out 10.000 Mails in 10 Minutes, every server would generate a auto-answer or bounce message:

You would get 10.000 Mails at once, never send out at least one.

A better idea is: Use the status Message to inform your user:

"550 Mail not registered. Please check your ... at http://..."

"That is why UCEProtect is a bad idea. Well informed system administrators do not use it. Even more because UCEProtect is set to make money from uninformed system administrators that fall in the trap of paying the express delisting fee." WE use UCEProtect! The delisting fee is about 50$, no so much. And the entries auto-expire after 7 days without impact. This a realy fair conditions.

What do you want? Spammers could delist themselve every day 100 Times?

Sry, but i don't open my mailsystem, because some mail-admins are still rfc-ignorants.

I have set up a temporary whitelist for you, so you have time to solve the problem.

If you need support, just ask. And i dont't want a "support fee" or something like this :)

You are still missing the point. This site does not reply to messages sent to addresses that do not exist, unlike you assume.

So if you send 10.000 messages to addresses that do not exist, they all be ignored.

The problem is that UCEProtect people are sending backscatterer messages to addresses that exist, which are of used by our users to send newsletter unsubscribe request messages.

Messages sent to those addresses from addresses of domains that we know that are spam traps, are ignored. But the rest of the domains that we don't know yet whether they are real or are spam traps, we need to send messages telling that there is no subscriber with that address.

We need to do that because some users register with one address but then it is forwarded to another address. They send messages with sender set to the forwarded address.

As I explained we need to reply to those messages from addresses that are not from any subscriber because if we do not do that, real users keep receiving no longer wanted newsletters and then report us as spammers.


As for UCEProtect charging money to discourage spammers to delist themselves, I am sorry but that is a silly excuse that nobody with good sense believes. Real spammers do not care of being listed by UCEProtect, even more because very few mail systems in the world use UCEProtect, so spam is hardly affected by UCEProtect ideas.

As for you whitelisting our server, I am sorry but it will not make a difference. We do not want to send you e-mail. It may be the users that have e-mail addresses under your domains that may care to register to the site, but they will not be able to do it using e-mail domains that you use because you used UCEProtect to bounce messages from our site and our mail system already blacklisted your domains.

Don't complain to us, we did not make you use UCEProtect. Complain to UCEProtect, they are the ones that decided to send backscatterer messages to our mail system and made us improve our mail system to blacklist domains that use UCEProtect.

I even don't understand your Problem.

Just include the mail-address where you send the message to into the footer.

Or add a mailaddress in VERP format ( unsubscribe-newclasses+customer=mail-server.com@phpclasses.org)

So, you don't need to send backscatters.

And again: UCE PROTECT IS NOT SENDING BACKSCATTERS! YOUR SERVER IS SENDING THEM!

[...]As for you whitelisting our server, I am sorry but it will not make a difference. We do not want to send you e-mail. It may be the users that have e-mail addresses under your domains that may care to register to the site, but they will not be able to do it using e-mail domains that you use because you used UCEProtect to bounce messages from our site and our mail system already blacklisted your domains.[...]

I don't understand, what you are trying to tell me. My Customers still get the mails from your system, even if you are a rfc-ignorant (and you are one!), because i have whitelisted your server localy.

You are still missing the point, as you admitted.

If you ever bothered to check the newsletter messages sent by the site, you would realize that it uses VERP to take care of bounces.

But it is not bounces that I am talking about. It is of newsletter unsubscribe requests sent by real users. The site tells them in each newsletter a simple address to where they can send their unsubscribe requests, so they can do it all by themselves.

I already explained you several times that users send those messages from addresses different from those used in their site accounts. So the site has to reply and tell them there is no user with such e-mail address, so they find a different way to unsubscribe successfully.

Anyway, I am not going to repeat myself further. If you still do not understand, ask a friend to try to read the above and explain to you in words that you can understand.

Other than that, I regret to notice that you are not able to disagree without departing to personal insult.

This site provides free resources to thousands of users with good faith spirit. When you feel that you should disrespect and insult the people that make this site accessible to you for free, the conversation ends here.

Sorry if it sounds like disrespect you.

I realy respect projects like this.

And i know that you use VERP for bounce handling.

But see:
Your mailserver (with mailman?) configuration could harm systems of 3rd persons. Your mailserver could be used for ddos attacks and more.

I understand the problem, people have mailforwards and the problem, unsubscription messages are discarded, if they are from a wrong mailadress.

But there is a simple way to workaround:

Add Informations about the original used email address into your footer. So everybody knows, what address was used for signup.

It also helps with another problem: The user doesn't remember, from which address he signed up.

That you are blocked by UCE is only a side effect of this misconfiguration.

Maybe UCEprotect is not your taste, but backscattering is realy a bad thing, belive me, i have to administrate mailsystems, and i have seen a DDoS with backscatters.

When you call me RFC-ignorant you are certainly being intentionally disrespectful.

The site mail server is qmail, but the software to manage and send newsletters, subscriptions and bounces is not mailman. It was totally written by me in PHP and has reasons to work as it is that surpass your understanding.

It is not viable to personalize all newsletters just to mention a different more complicated unsubscribe e-mail address. This was considered several years ago but cause more problems than it would solve.

The site already takes many hours to deliver newsletters that go to over 400.000 subscribers. If the newsletter messages body had to be personalized, it would take days to send a single newsletter to all subscribers.

On the other hand your argument is naive. If spammers really wanted to cause DDOS to any mail server, they would use their bot nets made of zombie PCs of inexperienced users around the world that had their computers infected by virus.

The point is that spammers usually do not want to cause DDOS. They just want to make their spam messages get to their spam victims so they can make money.

The fact is for that purpose sending messages to this site unsubscribe handler addresses will never make the original spam messages reach the spam victims.

When an user sends an unsubscribe request from a wrong address, the reply message that the site sends him does not contain any part of the original message body. So, this site unsubscribe system is useless to spammers.

Who in reality is sending backscatterer messages to this site is UCEProtect people. Their tactics claimed to solve the spam in the world, not only will not solve anything, but only upset people that manage innocent sites like this. It is up to you to realize that and stop hitting the wrong key bothering the wrong people.

Please,

inform yoursef about what "backscatter" realy is. ( http://en.wikipedia.org/wiki/Backscatter_%28e-mail%29 )

again: UCEprotect IS NOT SENDING BACKSCATTERS!
Maybe UCE is "produces" these backscatters, sending mails to your server. But why should the do? And that is not the core of this topic!

And there are more on the world wide web, abusing the systems, not only spammers.

I must say, the application seems to work relay nice :)

But you could improve the "unsubscribe" feature so many way's without backscatters ....

So, if you written the application, why you don't include a "unsubscribe" link into the mails?

Or, let qmail check the sender against the subscriber database, and if the sender not exsits, reject the message with and include the needed informations into the response message of the mailserver. So the person, who want's to unsubscribe with a wrong mail address will get a bounce message from the own mailserver (and you will never produce backscatters again), with all the informations she/he need.

Is it realy so much to code, that harming your and 3rd persons systems is "cheaper" ?

It makes no sense to speak with you about this, sry. And that is the reason why i call you "rfc-ignorant". You don't want to be "disrespectful" about our work, just about this one detail.

Goodbye

Ooops. my last sentence got a little bit out of order.

It should be: "I don't want to be "disrespectful" about your work, just about this one detail."

Sorry, to long without sleep, and to many work =)