Risks of .forward-ing?

Stupid Newbie Question:

Is there any way to "safely" forward email messages from a Linode to Gmail in a way that both doesn't conflict with SPF, and if the message is spam, doesn't make Google's systems think that the original source of the message is the VPS?

(And no, outsourcing MXes to Google Apps can't happen.)

I'm quite sure the answer is "no"… but I'd be very happy to learn that I'm wrong about that. I can't really "afford" putting the whole SpamAssassin/ClamAV bundle on the server… and I still feel it's quite an overkill, especially as this whole post has been triggered by one (first ever, after 4 months of uptime) spam message that wasn't rejected on the submission time and actually guessed a local user's name.

Yes, I could disable support for per-user .forward files and tell them to use the Gmail POP client, changing the action from push to pull. But it polls the remote accounts only every 30+ minutes… and that's too long in some cases.

(It'd be really nice if Gmail had a "relayer whitelist"… which would never submit specified machine to RBL even if some of the messages sent to the whitelisting account were spam…

What? I can dream, right?)

Hope you had a good laugh,

-- rsk

7 Replies

SPF is fundamentally broken, as your predicament illustrates. Simply don't use SPF, and then forward your mail.

Well… the SPF thing was a side note, actually. I'm way more afraid about the possibility of forwarding spam, which'll be then seen by Gmail's filters as originating at my Linode. (SPF simply makes that even worse; recommended way of forwarding SPF-protected mail is by performing SRS, in which case a spam message would have even more false clues pointing to the forwarding node being the original source.) For now it was a single spam message that got thru the basic SMTP-time tests, but I'm a bit afraid what could happen if that number would increase.

Oh, hmm…. I'm not sure how Google will handle that.

For what it's worth, I've run the full Spamassassin/ClamAV on my lowest-end Linode, well before it was a 360, without problems. While hosting Web sites, handling a fair amount of email, etc.

FWIW, I've been doing just that, using .forward to forward mail to my GMail account since the beginning of 2005, and so do a number of other users on the mail server. The mail server does filter almost all spam out, but some still manages to get through and gets forwarded to my GMail account.

GMail has never (so far) marked my server as a spam relay, even though GMail does filter the few spam messages that get through. This leads me to believe that GMail doesn't use the originating IP in determining if a message is spam (or it gives it a really low score).

I'd say you're safe using .forward.


Use .procmailrc instead. This will rewrite the sender of all of the email to be your server, so SPF should always pass.

:0 fw
* !^X-Loop: example@gmail.com
| /usr/bin/formail -A'X-Loop: example@gmail.com'

:0 A
! example@gmail.com

Note that Gmail will still reject email from eBay/Paypal. For some stupid reason, rather than using SPF, Google decided to do their own thing, which ignores the rewrite.


Note that Gmail will still reject email from eBay/Paypal. For some stupid reason, rather than using SPF, Google decided to do their own thing, which ignores the rewrite.

Are you sure? I forward all of my email to google (using the same procmailrc trick you do), publish SPF for my domain, and get my paypal and ebay emails just fine…

Not totally sure. I converted to Google Apps half a year ago cause I got sick of it all :)


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct