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 [email protected], [email protected], [email protected], they can set this up so that one of those accounts is a POP/IMAP account, for argument's sake say [email protected] is setup as a POP/IMAP account. Then just forward [email protected] and [email protected] to [email protected] This way, the user only has to log into the [email protected] e-mail account through webmail and they would have mail that is sent to [email protected], [email protected], and [email protected]

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

 

[wptechno]

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.

The only problem with this that the client wants to have their .com email forward to their aol webmail, so they only have to go to one place to check email. Some Clients can be very picky when it comes to what inbox they choose to use when they've been using it for years. That's all, I guess it's my job to try to ease them off of the commercial webmail accounts and into outlook or something like that.

 

[rs-freddo]

The only problem with this that the client wants to have their .com email forward to their aol webmail, so they only have to go to one place to check email. Some Clients can be very picky when it comes to what inbox they choose to use when they've been using it for years. That's all, I guess it's my job to try to ease them off of the commercial webmail accounts and into outlook or something like that.

Surely they can setup forwarders from AOL to their cPanel webmail. Still just one place to collect email, still webmail...

 

[sparek-3]

If I may be slightly blunt for a moment, I think clients just need to realize that this is something that they cannot do any longer. If a client has an @aol.com address and that is the only address they want to check, then they do not need to create any @theirdomain.com mail addresses. They need to only use that one @aol.com address. Someone asks them for their e-mail? They give them their @aol.com address. They want to post their e-mail address on their website, post the @aol.com address. Its really that simple. People might argue that it doesn't look as professional if you are a business and you are telling people to write an @aol.com address. Well, you just have to pick one or the other. Either only use the @aol.com address or learn to use an e-mail client or learn to use cPanel's webmail offerings and set up specific @theirdomain.com addresses.

There's not much any other way around this. You can do the forwarding thing, but its going to cause problems. Users forward their @theirdomain.com addresses to their @aol.com address and pretty soon AOL is blocking you. Then nobody from your server can send to @aol.com, not even the @theirdomain.com forwarders. This means that people will miss e-mails. The same can be said for Yahoo, Hotmail, Gmail, Verizon, Comcast, Earthlink, any service that you are forwarding your e-mail to.

I really don't have that much of a problem with AOL doing the blocking thing. I guess I might argue that AOL (or any other e-mail company) shouldn't be blocking mail at all. But to think, if nobody on your server forwarded e-mail to @aol.com, if AOL then blocked your server, it'd be a pretty good guess that someone from your server is sending spam or sending out messages to AOL customers who think the message is spam. At least in this case, you can work to find who is sending the messages and take action against that single account. If users are forwarding their mail to AOL, and AOL blocks your server, how do you explain that to another client on your server that is trying to write their friend (legitimately) who is using AOL? If you are going to point a finger at a party because of this entire issue with forwarders and e-mail blocking, I think that finger has to be pointed at the client or perhaps us as webhosts for not educating the end users as well.

I have tried my best to educate users, explaining in these similar terms why forwarding mail off of the server is such a bad idea, yet they still continue to do so. At this point, I'm really at wits end. I've been told that telling people that they cannot forward their mail off the server is a bad idea, but practically I don't see any other choice. It ultimately comes down to what I described in my first paragraph, either use one address or learn another way to do it.

Like I said, this is me being a little blunt and untactful and I'm not trying to make anyone mad or angry. But I think this is just the way it is. This thread was started to try and find a solution to this issue and I still don't see a solution, outside of just not allowing e-mails to be forwarded off of the server, but I would love to hear any other's input or if there happens to be another solution I would be all ears for it. I just don't think there is one.

I will step off of my soapbox now and hope that I didn't offend anyone, if I did I am sincerely sorry.

 

[chirpy]

I can only agree with your arguments. Whenever we run into similar situations with AOL or BT (in the UK) we simply walk the client through POPing their email from the server instead of forwarding it. It solves the problem completely then and the client is usually grateful for the help and personal attention.