I have a forwarding rule with Postfix that forwards all messages to my main email address, not hosted on linode. When a spam message is sent to my linode-hosted address, it is forwarded but the sender is shown as being my linode domain, not the spammer's domain.

Real example:

admin@spammer.cn sends an email to info@mylinodedomain.com

the mail is forwarded to myemail@notlinode.com

my email hosting (notlinode.com) sees it's spam and sends a message to abuse@linode.com

Result: I received a message that a spam message was sent through my linode and my linode was powered down (TOS violation) since I wasn't around.

I have modified my postfix settings so I now use RBL, but if a message goes through, it may happen again.

How can I prevent this to happen again?
Is there some settings to change on Postfix so the original sender is correctly identified?

Thanks
Stephan

The thing is that if you have a setup where mail is delivered to your linode and then forwarded somewhere else, the final destination will see the mail coming from your linode... simply because that's where it received the mail from.

I think your email host needs to add some sort of trust on your node's IP. That way they will start their spam research on the IP before you.

OK, but it should report the original sender also, no? I tested an email with spamcop.net and it doesn't recognize the original sender, just the forwarder.

The headers have a trail of where the message has been passing through, but the headers can only really be trusted if you trust the server you got the message from. (That last statement can be applied recursively.)

The problem is that every line of the Received: headers that are in the message could be a lie, from the perspective of the final receiving machine. They are very easily (and very commonly) forged, so we can't trust them.

The final receiving machine can only trust the IP address used to connect to it (and it puts that in the last Received: header; it's the only one the machine can trust because it wrote the line itself), nothing else.

In some cases it's possible to set up a "trust" where the machine can be told 'my linode is trusted', and then the machine could trust the Received line your linode writes out. But not many people bother to implement this. It's normally easier to whitelist your linode and so turn off the spam filter for messages relayed via your linode. You need to talk to your mail provider to work out how to do this.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

So it means that if a single spammer passes my anti-spam settings, my linode can be listed as a possible spammer and will be powered down because of a TOS violation?

How do you manage this case?

1) Talk to the people you forward to; if they can't/won't accomodate you by whitelisting your linode then stop forwarding to them.

2) Talk to linode staff; they're people. They might be able to help. Note, however, that even if this is possible and linode won't power you down for this it could still end up with your linode on RBLs.

3) Run your mail service all yourself and don't forward elsewhere at all

4) Can the remote end be configured to pull from your machine (so you deliver mail local to your linode, then the remote service does a periodic pull - eg POP or IMAP) to collect the new messages.

Basically, forwarding mail is not a good thing to do in this modern spam-filled internet.

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Since I'm juggling with 2 linodes, I had the MX record incorrectly set.

Now parsing a forwarded email through spamcop.net correctly identify the original sender.

Anyway, the steps I did to try to solve are:
- Added RBL checking to postfix
- Added postgrey to postfix
- Correctly set the MX record

I will also try to contact my email hosting to see if they can whitelist my linode.

Thanks,
Stephan

You REALLY should stop trying to fix this and listen to everyone who is telling you it is simply a bad idea to be forwarding mail to a host you don't control.

No matter what you do at your end, you will end up forwarding some spam. Your server will then be held responsible for the messages, no matter what the received headers say about who supposedly originated the mail.

Also, if the receiving server is checking SPF then even legitimate mail you forward will look like spam unless you implement SRS.

I use virtual alias maps with Postfix to forward mail to my Gmail.

jeff@example.com jeff@gmail.com

Based on this discussion, sounds like that's a bad idea? And could lead to a TOS violation?

If you're worried about inadvertently sending a spam complaint to abuse@linode.com because you receive mail forwarded through your Linode, you might want to avoid sending automatic spam complaints.

Spam doesn't randomly jump out of a dark corner and hit you over the head with a frying pan; it is an e-mail message, and just as human intent was required to send it, human intent is required to properly react to it. Mail forwarding has been around since the time of Moses and is a widespread, normal practice. I'm not going to take drastic measures(*) because someone has the spare time to sit and fire off 50 spam complaints an hour, even less so if they entrust a computer with deciphering mail headers without bothering to tell it not to dump its sewage upstream of the village.

(*) Although I do re-envelope forwarded messages, such that the envelope sender is the forwarding machine's postmaster. Works around SPF and keeps downstream errors from befuddling senders.

_________________

/* TODO: need to add signature to posts */

So Google isn't going to send off a spam complaint to Linode?

Probably not with this usage pattern, no.

_________________

/* TODO: need to add signature to posts */

For some addresses I do something similar on my server with postfix, except I have it deliver to a local user account. The only thing in that user account is a .procmailrc file that runs it through spamassassin. All mail above 10 points is discarded, 5 points is quarantined, anything else is forwarded to the final address.

http://www.spamtips.org/
Spamassassin needs some add-ons and tuning to work to its full potential. My blog here documents all the best configurations and warns against typical mistakes.