Jump to content

Blacklisted ... I know why


r3dlight

Recommended Posts

Hi all,

First of all forgive me for my english ;o) it's too bad ...I know

I'll try to explain my problem quikly:

My company manages 200 dedicated servers and a lot of them are in Africa (so it's clearly impossible to perform a LDAP check for users because of the delay). So we're blacklisted (see I've read the FAQs :o) because of that :

bounce emails sent after acceptance of the email instead of being rejected by the server during the SMTP phase

...

Of course, we sell an "email forwarding" service to our clients and that's the point. Actually our server cannot check for users or it would be really too long.

So to fix this, I don't see any solution.

I'm thinking of creating a dedicated email box (bounce[at]company.com) and redirecting every bounced email inside to recreate a new email.... but as you see, it's a really 'dirty' way to fix this problem and it seems that postfix do not perform header_checks on bounced emails... so if you could help, it would be great !!

I'm new on this company and my first goal is to fix it ... I hope I won't be fired soon lol...

Thank you very much for your help.

Link to comment
Share on other sites

Welcome to the forums R3dlight,

Presumably the problem is that your servers are bouncing spam emails (with forged sender addresses) to third parties who then report them. If so, there are ways of preventing this as covered in http://www.spamcop.net/fom-serve/cache/329.html#bounces and http://www.spamhaus.org/faq/answers.lasso?...20Spam%20Issues - if you need more information, please give details of the email server software you are using.

The problem is not authenticating your users but seeing if the email has a forged sender address first - features like SPF and DomainKeys can help verify the address but not everyone uses them. If you use a spam filter though, the easiest option is to set it to discard, rather than bounce, spam.

Link to comment
Share on other sites

Hi & thank you for your help...

Actually, it's not just for spams... for exemple: if an email is sent to a user who is just 'over quota', a bounced email is sent back to our postfix server after it was originally accepted. I've read that in the links you gave me :

If you must accept delivery before you know the status of a message, then file it internally - do not send, forward or bounce it outside your organization. The errant message can be placed in a special folder or routed to your postmaster.

Ok but we must notify the sender that the user was overquota ... I don't know if I'm clear (sorry again for my english).

Anyway, any ideas are welcomes ...

Link to comment
Share on other sites

Ok but we must notify the sender that the user was overquota ...

There are various ways that you can notify the sender that the user was overquota without sending spam to innocent people.

You need to give the name of email server software that you are using. other forum members can tell you how to notify the sender without sending spam to forged addresses.

Miss Betsy

Link to comment
Share on other sites

Ok but we must notify the sender that the user was overquota ... I don't know if I'm clear (sorry again for my english).

But you're NOT notifying the sender! You're spamming an innocent 3rd party - that's why you're listed.

Link to comment
Share on other sites

We have a postfix 2.2...

Is a bounce generated by a mail server a spam ?

I don't understand you when you speak about spams ... what do you mean ?

Because ... we must forward emails (so accept them) via VPN's for our clients ...

Link to comment
Share on other sites

Is a bounce generated by a mail server a spam ?

I don't understand you when you speak about spams ... what do you mean ?

Most (all?) spam these days have forged return addresses.

Bad way:

You accept a spam message addressed to one of your domains that has a delivery problem. Your server then sends a "bouce" message to that forged address. You have just sent that person unsolicited email, aka spam.

Good way:

You accept a spam message to one of your domains that has a delivery problem. Your server sends the bounce message to a "problem account" which you check or does not send a message at all. SMTP is not a guaranteed delivery mechanism. SPaMMERS HAVE RUINED THIS PART OF smtp.

Better way:

You check for valid delivery during the SMTP process (something you say is impossible, but others are doing it, SMTP will generally wait if setup properly). Invalid messages are rejected by the server and the sending server generates a message to the sender which should have been authenticated.

Link to comment
Share on other sites

There are two kinds of 'bounces'

The first is when the server does not accept the email and sends code back. The sending server then composes an email to send to their customer.

The second is when the server accepts the email and then decides what to do with it. If the server 'returns' it, it has to send an email to the return path or From. The spammer forges the return path or From with someone who did not send the email. Therefore some innocent person gets a spam (an unsolicited email usually advertising something) as a 'bounce.' These bounces are just as annoying as getting unsolicited email (spam). A person can get hundreds of them.

spam is any email that a person did not ask for and does not want. Usually, a spam email is selling something. Sometimes the spam email is from a criminal who wants to get passwords or to trick you out of your money. Many times the spammer puts a trojan in someone else's computer and sends the spam from that computer without the computer owner's knowledge. You also need to make sure your customers are not sending spam. You look at your logs for other ports to find out if a computer has a trojan.

Of course, if you did not send a message, an email telling you that an email you didn't send is not an email that you asked for. Therefore the second kind of bounce is spam - an email that you didn't ask for and don't want.

I am not a server admin so I cannot explain how to set up your server so that it does not send emails people do not want.

Miss Betsy

Link to comment
Share on other sites

Ok, thank you for your replies,

... so now my questions are :

How can I inform a regular user that his email can't be delivered because the destination account is over quota for exemple...?

How can I redirect bounces to a special email account with postfix 2.2 ? (header_checks doesn't checks bounced emails)

..StevenUnderwood

You check for valid delivery during the SMTP process (something you say is impossible, but others are doing it, SMTP will generally wait if setup properly).

...yes we can't check for valid users because it would take too much time (france to africa, or even france to australia)..

Link to comment
Share on other sites

...yes we can't check for valid users because it would take too much time (france to africa, or even france to australia)..
You don't need to check for a valid user, just lookup the domain of the senders' address to find its IP range and compare this to where the SMTP connection is coming from. If the connection is coming from an IP address outside of the domain it claims to be from, then it is likely forged and can be rejected.

Another approach covered in Postfix anti-UCE configuration is to do content and blocklist checks to identify spam and just reject that (you will need to customise the suggestions given there for your network). Running a full-fledged filter like spam-Assassin and rejecting any email that it flags as spam would be a more thorough approach.

Link to comment
Share on other sites

We already have spamassassin to manage spams ...

...ok but how can you make a difference between a forged email and a non-forged email ? in the case of a regular user who want to write to an account which is overquota ...

Link to comment
Share on other sites

We already have spamassassin to manage spams ...

...ok but how can you make a difference between a forged email and a non-forged email ? in the case of a regular user who want to write to an account which is overquota ...

Why can't you just reject it with a 5xx code at the time of the SMTP transaction if the recipient is over quota? that way the message gets back to the actual sender, not some innocent 3rd party.

Link to comment
Share on other sites

...ok but how can you make a difference between a forged email and a non-forged email ? in the case of a regular user who want to write to an account which is overquota ...
Compare the From address to the domain where the connection is coming from - e.g. if a connection is coming from the Comcast/Verizon/MCI network (164.109.0.0 - 164.109.255.255) but the From address is given as xxx[at]microsoft.com then it is most likely a forgery and can be rejected.

This can catch out those users who specify a webmail address like Gmail/Hotmail/Yahoo when using their normal ISP email, but these should be a very small minority and they will see the SMTP 5xx rejection message you send.

If your server has accepted an email which is then flagged as being spam, discard it without sending a response (you may wish to have "borderline" emails forwarded to a separate address for you to review and then bounce/discard as you see fit).

Link to comment
Share on other sites

Why can't you just reject it with a 5xx code at the time of the SMTP transaction if the recipient is over quota? that way the message gets back to the actual sender, not some innocent 3rd party.

--> Because our postfix server MUST forwards emails to others email servers (postfix, lotus etc...), then those servers check if the account is ok or overquota or if the user is unknown and they send back the bounce to our postfix server. Spams are already filtred at the beginning by the our postfix server... I don't speak about spams here (I don't know if I'm clear)

email comes here--->postfix forwards emails/&smtp ok and spamassassin cleans spams--->another email server check the account |

bounce back to the sender account <------ postfix (which cannot filter bounces)<--- if overquota send back bounce to

Link to comment
Share on other sites

Just a suggestion to get things on track ... please identify one or more of your "listed" servers such that someone can actually look at what the actual situation is. Your suggested scenario of "a few over-quota users" should not be enough (general case assumed) to get your servers listed. Suspicions are that there is more to the story. Let's start by looking at something specific

Maybe also see: Joe-job spammers shift tactics to evade filters .... another case or someone wrongly using the term "joe job" but the content should sound familiar ...

Link to comment
Share on other sites

Spams are already filtred at the beginning by the our postfix server... I don't speak about spams here (I don't know if I'm clear)
Then this is much easier - your spam filtering isn't thorough enough resulting in spam (with forged sender addresses) getting through and triggering a "spam bounce" which gets reported here. Review and tighten up on your spam filtering.
Link to comment
Share on other sites

We are an ISP so our clients will not accept that we stop bouncing back... it's not a few 'over-quota users' but we may reach around 1500 overquota accounts during vacations and without taking care of users who write a wrong email adress without paying attention ...

Review and tighten up on your spam filtering

...but all gmail/hotmail senders will be tag as spammers ...

Link to comment
Share on other sites

We are an ISP so our clients will not accept that we stop bouncing back... it's not a few 'over-quota users' but we may reach around 1500 overquota accounts during vacations and without taking care of users who write a wrong email adress without paying attention ...

...but all gmail/hotmail senders will be tag as spammers ...

Sorry, but your 'can't do' attitude is beginning to annoy me. Your present set-up is abusive and spam-friendly. People here make suggestions to help you and your constant reply is 'we can't do that'. OK then, stay on the blacklists. :angry:

Link to comment
Share on other sites

...but all gmail/hotmail senders will be tag as spammers ...
Why? Nothing suggested above would cause this to happen.

Basically you have 2 options:

  • check incoming mail to see if the From address matches the network where the connection is coming from or
  • check incoming mail for spam using other criteria (IP-based blocklists, content filtering, etc).

Mail in either of these categories should be silently discarded - borderline cases may be worth passing on to a special mailbox for admin review. Neither option should affect legitimate mail (with the single exception for (a) of users who post from one address while specifying a different return address - in this case, you can whitelist the return address they use).

Link to comment
Share on other sites

You could put a requirement for your customers in place that they MUST accept all mail that you forward to them. There is very little reason for mailbox quotas anymore. Years ago when disk space was expensive, quotas were necessary, but now, disk space is cheap, even for high end RAID setups. Some mail systems limited the maximum size of the mailboxes (I know the basic version of exchange limited this to 16GB) but now most of those have been lifted. Even Micro$oft raised the limit on basic versions of Exchange to 75GB. Mailbox quotas are left over from the early days of the internet, and should be removed for a more complex mail setup like what you are proposing.

You should also either do lookups during the SMTP phase to see if the email address actually exists, or require the customers to maintain a "catch-all" account for email addresses that don't exist. Distance is irrelevant on the internet, even the Australia to Africa scenario you are talking about is only a few hundred milliseconds at very worst. SMTP should hold the connection open for as long as you need to do the lookups.

Link to comment
Share on other sites

Well, Gentlemen,

First of all, let me explain our position.

As an ISP, one of our goal is to provide a service reaching the best quality for our customers. In that way, we are usualy more involve in fighting spams and spammers rather than to produce "unsolicited emails". We are not spammers and we don't aimed to become ones.

So we're looking for solutions about this issue, with your help indeed.

We provide different services, such as email forwarding, mailbox with quotas, auto-reply, anti-spam ect.

You will agree that setting quotas or not, have nothing to do with being a spammer or not. By this way, being blacklisted should'not be linked to the fact that quotas are used or not. Arguments about the use of quotas have nothing to do here. Quotas makes part of our strategy.

Ok let's summarize the whole thing :

The blacklisting reason is :

"bounce emails sent after acceptance of the email instead of being rejected by the server during the SMTP phase"

In practice, that case occure when an incoming mail is forwarded from a server A to a server B (In this case, our frontal Postix to another mail plateform). Then this server check the mail and notify the server A of any error (OverQuota,recipient error etc..). Then the server A bounces with the error message. The fact is, when first forwarded to server B, email is ACCEPTED, and then BOUNCED. Excepted the fact this is not a spam, we recognized that case is exploited by spammers.

Here are the preconized solutions :

- Discard Bounces

To discard bounce will indeed, cancel the problem. But discarding bounces will discard Over-Quotas bounces, and Invalid-recipient and any error from the sender. The mail won't be sent, and the user won't be aware of that.

- Discard and re-write a "clean" email to the sender with the Error Message

We've tryed with efforts to find a way to catch messages before they're discarded, the Posfix Developers themselves have explained us that bounces are never stored on the server but sent as soon as the message is received. This issue seems to occure on most of MTA. If you have any tips about that, we are interrested.

- Cancel Quotas

(See above)

- Check for valid delivery during the SMTP process

A lot of our users are from Africa, maybe distance is irrelevant on the internet but Africa backbones are those of the lowest. An important point is that a lot of our customers have their own LDAP servers, so when Postfix check for the valid user, it have to check one by one every LDAP servers until to find the valid entry. We have to multiply the ping loss with the numbers of LDAP servers requested. We've tried this way and excepted the fact the mail-queue grow very fast, we often reach the SMTP Timeout.

Here's an extract of ping session with Togo (some are Synchronous Sattelite Links or RNIS)

64 bytes from 10.89.1.35: icmp_seq=12 ttl=123 time=2030 ms

64 bytes from 10.89.1.35: icmp_seq=14 ttl=123 time=1842 ms

64 bytes from 10.89.1.35: icmp_seq=15 ttl=123 time=1980 ms

64 bytes from 10.89.1.35: icmp_seq=18 ttl=123 time=2162 ms

64 bytes from 10.89.1.35: icmp_seq=19 ttl=123 time=1812 ms

64 bytes from 10.89.1.35: icmp_seq=20 ttl=123 time=1990 ms

(We have similar problems with Oceania)

Here is the situation. You will recognize our present set-up isn't "spam-friendly" no more than our intentions.

We don't reply "we can't do that" to any suggestions, we're looking for solutions and suggestions that can be applied in our architecture without changing nor the service neither its quality.

I'm still persuaded there is a solution.

D.L

System Administror.

Link to comment
Share on other sites

Once again ... let's quit playing hypothetical games. Please identify one or more servers that you believe to be listed on the SpamCopDNSBL .... Until that happens, I'm out of here ....

Here's an IP address pulled out of the hat ....

http://www.senderbase.org/?sb=1&searchBy=i...=194.250.211.28

Volume Statistics for this IP

Magnitude Vol Change vs. Average

Last day ........ 3.9 .. 1757%

Last 30 days .. 3.2 ... 228%

Average ........ 2.6

Is this perhaps a sample of your "over-quota bounces" .,..????

Those kinds of numbers suggest something else entirely, unless you can come up with some other reason for the massive increase in traffic 'seen' ....

On the other hand;

194.250.211.28 not listed in bl.spamcop.net

Maybe this isn't one of yours, I don't know ... but the question of identity has been asked before.

Link to comment
Share on other sites

Hi Mr Wazoo,

Thanks for your response.

We are no more blacklisted on SpamCopDNSBL because we have unsuscribe,

But we have been blacklisted twice and I'm trying to anticipate the third time,

wich will logically happen soon if nothing is changed.

The first and the second time, Ip 194.250.211.27 was blacklisted.

We've have two LVS server, the 1St (the one which send the mail) was the 194.250.211.27.

We have recently changed the configuration so that the second (194.250.211.28) replace

the 1st (194.250.211.27). I reckon it was the 1st operation we did not to be blacklisted

a third time with the same IP. Now we know why it is useless.

That's why you see this growing traffic for 194.250.211.28

Link to comment
Share on other sites

The first and the second time, Ip 194.250.211.27 was blacklisted.

We've have two LVS server, the 1St (the one which send the mail) was the 194.250.211.27.

We have recently changed the configuration so that the second (194.250.211.28) replace

the 1st (194.250.211.27). I reckon it was the 1st operation we did not to be blacklisted

a third time with the same IP. Now we know why it is useless.

That's why you see this growing traffic for 194.250.211.28

Thank you for finally providing some concrete information.

Neither IP is showing any "human" reports against it so I will need to assume your messages were hitting the spamtrap addresses. That is the main problem with bouncing after the fact. The spamtrap addresses did not send the messages you were bouncing. Of course, it is also likely you were sending these same types of messages to lots of other innocent victims. You can contact the deputies to get some information about the types of messages hitting the traps (confirm it is over quota, invalid user, or real spam somehow coming from the IP address).

Parsing input: 194.250.211.27

host 194.250.211.27 = csi-msg-lvs1.c-si.fr (cached)

host 194.250.211.27 = csi-msg-lvs1.c-si.fr (cached)

No recent reports, no history available

Routing details for 194.250.211.27

[refresh/show] Cached whois for 194.250.211.27 : ebodilsen[at]c-si.fr

Using last resort contacts ebodilsen[at]c-si.fr

Statistics:

194.250.211.27 not listed in bl.spamcop.net

Parsing input: 194.250.211.28

host 194.250.211.28 (getting name) = csi-msg-lvs2.c-si.fr.

host 194.250.211.28 = csi-msg-lvs2.c-si.fr (cached)

No recent reports, no history available

Routing details for 194.250.211.28

[refresh/show] Cached whois for 194.250.211.28 : ebodilsen[at]c-si.fr

Using last resort contacts ebodilsen[at]c-si.fr

Statistics:

194.250.211.28 not listed in bl.spamcop.net

Link to comment
Share on other sites

We are no more blacklisted on SpamCopDNSBL because we have unsuscribe,

One does not unsubscribe from a SpamCopDNSBL listing .. so will make an assumption that this is a language / translation thing ... "de-listed" is what I'm guessing as what was meant.

That's why you see this growing traffic for 194.250.211.28

A much better reason than the typically spammer infested / controlled systems those numbers usually indicate.

Neither IP is showing any "human" reports against it

Possible glitch there, as I've not heard anymore since, and one of the statistices pages is still showing some funky data ... see Don's reply at http://forum.spamcop.net/forums/index.php?showtopic=6373

You can contact the deputies to get some information

Just a pointer .. please provide the "technical" data at first contact ... that staff of 3 people trying to handle (last time it was brough up) 800-1200 e-mails a day ...

on the other hand, no hits at http://groups.google.com/groups?scoring=d&...8+group:*abuse*

no hits at http://groups.google.com/groups?scoring=d&...7+group:*abuse*

nothing of any consequence at http://moensted.dk/spam/?addr=194.250.211.27&Submit=Submit

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...