How to stop bounces for forwarders?

[LBJ]

G'day All,

One of our servers just received a complaint from SpamCop for delayed bouncing of mail which was undeliverable at the final destination pointed to by a forwarder.

SpamCop's info on the subject is at...

http://www.spamcop.net/fom-serve/cache/329.html#bounces

It's a totally valid point, in that if spam using a spoofed sender header is sent to a forwarder, our server will try to deliver it for a set time. If it's ultimately undeliverable for any of many reasons, a bounce is sent back to the spoofed sender. That bounce to the innocent user whose email address has been spoofed definitely meets the criteria of spam.

Does anyone know whether bouncing notification can be disabled in the case of local forwarders only?

Any simple or even complex solution would be well received.

Best Regards,

LBJ

[cynux]

I'm having the same problem on my server

[Spiral]

You could go for ":blackhole:" on that one but I really would
not recommend it for number of other reasons.

[sparek-3]

The only solution that I know of, is to just not use forwarders in this manner. This is probably not the answer that you are looking for, but its the only conclusion I have ever been able to come up with. Unless someone else has a better solution, I too would like to hear it.

The problem with forwarding e-mail to an off-server address (a 3rd party service) is that, that 3rd party e-mail service will see all e-mail that is forwarded off your server, they will see it as originating from your server. This includes spam messages. A user on your server may receive a spam messages from some other server, and then forward it to their ISP e-mail or some other 3rd party e-mail service. That e-mail service has no choice but to detect that message as coming from your server. No, you are not directly sending spam, but there is no way for the 3rd party mail server to know this. If the 3rd party server receives enough spam from your server, it may block your server.

This block is bad for two reasons (or three). First, your user will no longer be able to forward any e-mail to that service, meaning that they may lose e-mail. As a side effect of this, anybody else on your server that writes legitimately to friends or users of this 3rd party service, they won't be able to write them either because your server is blocked. The other reason, is that you get this situation that you have described. Mail is suppose to be forwarded to a 3rd party e-mail service, that service is blocking your server, that mail eventually times out and your server will send a message back to the sender. This sender (in the case of a spam message) is never the spammer. It will either be an innocent person who just happened to have their e-mail address attached in the From line for that spam message, or the From line would be set to a non-existant address. In the case of an innocent user, then again, your server is sending spam back to that person in the form of a bounced message. In the case of a non-existant e-mail address, the mail just sits on your queue trying to be delivered, but it can't because the e-mail address is invalid. The mail will eventually time out and get deleted.

The short part is, if users want to use e-mail addresses for their domain, they are much better off to just set up e-mail accounts (POP or IMAP) on your server and check them directly. This way they are not forwarding mail off of the server and none of these issues ever arise. The only time any issue would arise is if the user goes over the specific mailbox quota for that mail account or if the user's main account ever reaches its quota. The other alternative, is to have the user advertise their forwarded address directly. For example, if they are forwarding mail to a hotmail.com address, then this hotmail.com address should be the address that they give out to people and not an @theirdomain.com e-mail address which forwards to that hotmail.com address. It may not look as professional, but its just a give and take, and the user has to decide how they want to proceed.

You can use RBLs which may help in this situation. An RBL will work before the message is ever accepted. So if a known spammer address is sending mail to an e-mail account on your server that forwards to a 3rd party service, then the RBL would catch this and reject the message before it even gets the chance to be forwarded. The issue with RBLs is finding one that is not too strict, but also blocks a lot of spam. Even with an RBL setup, you will get some messages that slip through, so I don't really recommend the RBL solution.

Again, if anyone else has any other suggestions regarding these issues, I would like to hear them. I too have seen this issue and have looked for ways to resolve it. The above is the only solution I have ever come up with.

[LBJ]

G'day Spiral,

You could go for ":blackhole:" on that one but I really would
not recommend it for number of other reasons.

That's not actually making too much sense to me, I'm sorry. How exactly would you set just the bounce messgae from a deleyed delivery of an email from the smtp to ":blackhole:"?

The configuration to manage that would solve the problem nicely. I'm not worried about dumping bounce notifications if the alternative is bouncing spam to an innocent spoofed email address owner and then being blacklisted.

Best Regards,

LBJ

[LBJ]

G'day Sparek-3,

The only solution that I know of, is to just not use forwarders in this manner. This is probably not the answer that you are looking for, but its the only conclusion I have ever been able to come up with. Unless someone else has a better solution, I too would like to hear it.

I think I'm tending to lean that way also. With the current state of email spamming and blacklisting, I think the use of forwarders is really adding a non manageable high level of risk to our servers.

Even apart from the bounce issue, as you correctly point out, any email passed through the forwarding server is treated as having originated from that server. If it's spam, then the forwarding server is spamming. Pre filtering is obviously a must, but that has the risk of blocking false positives, and in any case will always allow a percentage of junk through.

It may be time for a shake up in responsible hosting plans and a removal of forwarders as an enduser option.

If anyone can suggest a workable and responsible solution to maintain forwarders as an enduser option, I'm more than willing to learn though.

Best Regards,

LBJ

[hostultra]

It depends on the isp's methods of detecting who sent the spam.

AOL *incorrectly* detects forwarded spam as originating from the forwarding server instead of the real spammer.

Spamcop correctly detects forwarded spam, and only complains to the isp of the spammer.

[chirpy]

Indeed - and it's very poor email management by AOL. But you do set yourself up to be blocked if you accept your server as a relayer by allowing users to forward their email on. The only way to counter such setups is as sparek-3 says, don't allow users to forward email in that manner and tell them to simply pop the email off the server. Most modern email clients allow them to setup more that one POP3 account, so it's of little consequence, considering the wider implications of allowing the forwarding.

[PWSowner]

The only way to counter such setups is as sparek-3 says, don't allow users to forward email in that manner and tell them to simply pop the email off the server. Most modern email clients allow them to setup more that one POP3 account, so it's of little consequence, considering the wider implications of allowing the forwarding.

I tend to agree with what sparek-3 said, but the problem is, most Hotmail, Yahoo, etc users don't use a POP program. They use the webmail and in not allowing forwarders, they have to log in to multiple webmail programs which they don't want to do, hence the forwarding. For our own protection though, those mail providers are forcing us to not allow forwarders.

[chirpy]

Yup, it's a real problem - but so long as AOL are happy, eh? Never mind their customers They really seem to be addressing spam problems in many and varied bad ways. SPF was the first bad example when it became apparent that it does nothing to stop spam, then came blacklisting IP's arbitrarily, and now this. You think that they'd be better focused at lobbying for proper spam laws from the greatest source (USA) instead of the cop-out which is the CAN-SPAM act, and the vacant hole of compromises which is the Windows OS and zonbie PC's.

Anyway, that's getting way OT.

[Stefaans]

Very interesting discussion. This is an issue that has been bugging me too.

One of you clever guys (how about it Chripy? ) will probably be able to figure out what is said here and suggest something workable for us:

http://www.exim-users.org/forums/showthread.php?t=50017

[sparek-3]

I am actually glad to see this "issue" getting some focus. To address a few issues that have been brought up:

AOL *incorrectly* detects forwarded spam as originating from the forwarding server instead of the real spammer.

Spamcop correctly detects forwarded spam, and only complains to the isp of the spammer.

I may be wrong in regards to this, but I don't believe Spamcop does any type of real time blacklisting or real time identifying of spam messages. Spamcop works by accepting the full message, all of the headers, then examining the message and adding the original source to its RBL list. AOL (and other 3rd party e-mail services) block messages in a more real-time structure. A message is sent to their system, they identify it as spam using some arbitrary method, and then block the server that was responsible for sending them the message (in the case of forwarded e-mails, your server). I'm not entirely sure how Spamcop works, but I'm thinking there may be some type of human element there that is able to correctly identify the original source, whereas AOL does not (and probably cannot) employ such a function.

They use the webmail and in not allowing forwarders, they have to log in to multiple webmail programs which they don't want to do, hence the forwarding.

There is nothing wrong with forwarding e-mails within your own domain or even the same server. This forwarding issue just applies when e-mails are forwarded off of the server. For example, if a customers wants to receive e-mail at support@domain.com, sales@domain.com, abuse@domain.com, they can set this up so that one of those accounts is a POP/IMAP account, for argument's sake say support@domain.com is setup as a POP/IMAP account. Then just forward sales@domain.com and abuse@domain.com to support@domain.com. This way, the user only has to log into the support@domain.com e-mail account through webmail and they would have mail that is sent to support@domain.com, sales@domain.com, and abuse@domain.com.

Further, if these individuals do not like the webmail interfaces that are offered in CPanel, and wish to stick with their hotmail.com or yahoo.com interface, then they really just need to be using their @hotmail.com or @yahoo.com e-mail address when they tell people to write them. If they don't like that, then tough. Its just not possible to make everyone happy, and individuals need to realize this.

It should also be noted, that I'm not really complaining about AOL, Hotmail, Yahoo, and other 3rd party mail services and their anti-spam policies. They have to protect their clients as well. I do believe that AOL's tactics may be a little too much, this is just something that is between them and their clients. The issue with these services blocking servers because of forwarded e-mails, is not really their fault, its really more the fault of end users and having to forward their mail to these services. I just don't think end users can fully understand the situation and what is going on, and why forwarding mail to these services is such a bad idea. And so far, I haven't been able to come up with an explanation that end users can fully understand. The way that I describe the problem, and the way other users here are describing this problem, I can understand, but trying to convey that message to end users is not that simple.

There is another thread that is somewhat on this topic at:

http://forums.cpanel.net/showthread.php?t=52910

I don't want to go too much off topic in this thread, but I am paying close attention to both of these threads. I am interested in seeing how the webhosting community reacts to this issue and whether or not disallowing e-mail forwarders will become a viable option. Personally, that is where I believe it will eventually go, I'm just not sure how soon we can expect it to really hit mainstream. But again, that's a topic of discussion in the other thread, and I don't want to take this thread off topic.

[LBJ]

G'day All,

We've now contacted all our hosted clients and explained that forwarders may now only be used as aliases to existing mailboxes on their own domains.

We're now scanning our /etc/valiases/* each day and killing any forwarder created to send to any external domain. We allow a few exceptions for forwarders to our own domains used for hosting mail for our ISP dialup and ADSL clients. We're not likely to blacklist our own hosting servers. :-)

I had a look, but I couldn't find any configuration option within WHM/CPanel to limit forwarders to local domains only. Am I just missing it, or do we actually need to code that ourselves?

If the latter is the case, then given the widespread problem, as evidenced in this thread, that's definitely something which should be available as standard within WHM/CPanel.

Where's the official suggestion/wishlist area for the product?

Best Regards,

LBJ

[chirpy]

To make a suggestion you need to create an enhancement request entry in http://bugzilla.cpanel.net. If you then link to the entry in this thread others can vote on it.

[LBJ]

G'day Chirpy,

To make a suggestion you need to create an enhancement request entry in http://bugzilla.cpanel.net. If you then link to the entry in this thread others can vote on it.

Thanks for that.

The bugzilla on that is here...

http://bugzilla.cpanel.net/show_bug.cgi?id=4177

Best Regards,

LBJ