Received #5:
by 10.220.149.77
(no 'from' clause)
Received #4:
by mx.google.com
from gourmet8.spamgourmet.com (gourmet7.spamgourmet.com. [216.75.62.102])
Received #3:
(no valid 'by' clause)
from spamgourmet by gourmet7.spamgourmet.com
Received #2:
by gourmet7.spamgourmet.com
from mail-vc0-f171.google.com ([209.85.220.171])
Received #1:
by mail-vc0-f171.google.com
(no 'from' clause)
The 'by' clause in a Received header should match up with the 'from' clause in the next prepended Received header (and why I reversed the 'by' and 'from' clauses so they were next to each other across the Received header line). The exception would be for internal handling or routing within the same e-mail system. So analyzing from the first to last Received headers:
Received #1: Your e-mail started at Google.
Received #2: It went out Google's boundary SMTP server to reach Spamgourmet.
Received #3: Not an RFC compliant header. The 'by' token should be the the by-clause delimiter but here instead shows the from-clause info). Should be:
Received:
by spamgourmet
from gourmet7.spamgourmet.com
The by-clause here doesn't show host specific info since it is a placeholder for internal handling or routing.
Received #4: Somewhere in the internal routing for the Received #3 header, it eventually routed to the external or boundary server of gourmet8 which then connected to the SMTP server for Gmail.
Received #5: Another poor header definition. Should've include the boundary host; however, 'mx' probably redirects to a server farm and they don't want to let you know or map out their farm. Consider this an internal routing header that didn't show proper connection to the prior Received header.
So your test e-mail did leave the Gmail domain, went to Spamgourmet, and came back from Spamgourmet to Gmail. So it went outside and came back in. The problem is with the following header:
Received:
by gourmet7.spamgourmet.com
with <infoparms> (envelope-from <trueaddr@gmail.com>)
from mail-vc0-f171.google.com ([209.85.220.171])
While it would be preferred that Spamgourmet strip out ALL headers (except those inserted by the sender's e-mail client, like To, CC, Subject, Date, Content-Type, etc) and have Spamgourmet start fresh with a new batch of headers so it looks like the e-mail actually originated from Spamgourmet's domain, its owner has stated it is not the intent of his service to hide the origination of an e-mail. That is, while Spamgourmet tries to hide your true e-mail address, it does not hide from where your e-mail originated. If it originated from Gmail, the recipient sees your Spamgourmet alias in the From header but the headers will still show your e-mail originated from Gmail. Similarly, if you configure your e-mail client to say your e-mail address was <me>@yahoo.com and you send through Gmail's services, the recipient will see your Yahoo e-mail address in the From header but other headers will still show that you sent it from Gmail.
The Received header is generated by the server that receives the message. That is why, for example, spammers don't like they cannot control the 'from' clause added by the receiving server outside their control. The best they can try is to insert a bogus Received header and hope users get misled in tracing the source of the spam by using that bogus header. The 'from' clause is added by the receiving server to identify who connected to it. Every host knows who connected to it (by the other host's IP address, at least). The receiving server adds its own 'by' clause to identify itself (and why some are poorly constructed). So Received #2 was generated by Spamgourmet, not Gmail, and therein lies the problem. Spamgourmet is adding its own envelope-from info parameter (everything past the 'with' token) that reveals the sender's true e-mail address. Spamgourmet should not be adding any envelope info.
"Envelope" means the values in the commands sent from one STMP server to another. Those values are NOT from any existing headers within the message. Envelope-From is derived from the value specified by the "MAIL FROM" command sent by the sending server (not from the client-inserted From header). Users often don't get to see any of the envelope info because they don't get a log of the commands and their values sent between SMTP servers. Servers can, however, add the envelope (command data) as info parms into the headers that they add to the message. So Gmail connects to Spamgourmet and send something like:
Gmail: EHLO ...
SG: (response codes)
Gmail: MAIL FROM: <trueaddrs@gmail.com>
SG: +OK
Gmail: RCPT TO: <recipientaddr> SIZE=<octets>
SG: +OK
Gmail: DATA
SG: 354 Start mail input, end with '<CR><LF>.<CR><LF>'
Gmail: (sends message: existing headers + body)
Gmail: .
SG: +OK
Gmail connects. SG response okay (to start the mail session). Gmail sends the "MAIL FROM" command (don't know why since it isn't needed to route forward to the recipient). SG says okay. Gmail tells SG who is the recipient using the "RCTP TO" command. SG says okay (syntax is good). Gmail sends the DATA command to say it is ready to send the message (existing headers + body). SG says it's okay to send. Gmail transmits the message. A trailing line of just a leading period character following by a newline (i.e., just a period in the line) from Gmail tells SG that is the end of tranmission of the message. SG says it got it okay. Why Gmail sends the "MAIL FROM" command is unknown since it isn't needed to route the message to the recipient (only the "RCPT TO" command is needed). Spamgourmet is adding the value specified by Gmail in its "MAIL FROM" command into the "envelope-from" info parm in its 'by' clause of its Received header. THAT IS THE FAILURE.
Spamgourmet should not be showing any info from the SMTP commands in envelope info parms in any header it adds when routing forward a message that it received. It will use the RCPT-TO command to know what to specify in its own RCPT-TO command that it sends to the next server but not even the value of RCPT-TO should be added to any header inserted by Spamgourmet (since the value of RCPT-TO could be different than the value of the client-inserted To header, like when sending a newsletter where To names the newletter and does not list the actual recipients). Envelope info used during the SMTP transaction should not be showing up in Spamgourmet-generated headers.
http://tools.ietf.org/html/rfc5321Section 3.3 - Mail Transactions
If you read that, yes, I can see why the "MAIL FROM" command was sent to identify the originator of a message to the receiving mail server. This starts the mail session between sending and receiving SMTP servers. That does NOT means Spamgourmet should include the origin info in the headers that it later adds when sent out through SG's boundary mail server. SG should not include this envelope info -- *IF* the message is going *out* of an SG account (i.e., you're sending a reply through SG) but it's okay if the message is coming *in* to an SG account (i.e., you're getting someone else's e-mail sent to your SG alias). So I have to wonder if you actually sent a reply to a received SG-aliased message or if you originated a new message that went thorugh SG (like you were the recipient of a reply to an SG-aliased message).
You give an SG alias to someone. They send you a new e-mail through that SG alias. It's okay for SG to include the envelope info because SG isn't trying to hide who it is that is using your alias to send an e-mail to you. This is e-mail coming from outside from someone using your SG alias. When you reply is when SG should hide your true e-mail address. When you reply to an aliased e-mail is when SG should *not* add any of the SMTP command (envelope) information.
In your test, did you:
- Send an e-mail to your alias (new e-mail).
- Then reply to that aliased e-mail (reply e-mail).
- Look at the headers in the reply e-mail.
SG would then massage your *reply* to hide your true e-mail address. If you're looking at the *new* e-mail you sent into your SG alias then it's not SG's job to hide who was that sender. SG doesn't hide who sent you e-mail through an alias. SG only hides you when you REPLY to an aliased e-mail (i.e., when you reply). From your description, I'm not sure if you initiated a new e-mail into your SG account and then investigated the reply that you sent back or if you just looked at the first (new) e-mail sent into your SG account.
sender: to your alias --> SG acct --> your real acct
That doesn't need to hide the envelope info. SG isn't trying to hide the sender using your alias.
sender: to your alias --> SG account --> your real acct
followed by
you: send reply to aliased e-mail --> SG account --> sender: sees ony your alias
That should NOT include any envelope info in your REPLY that the sender gets back.
Did you send a test e-mail through your SG alias and look at what you received? Or did you reply to an e-mail that was aliased through SG? For your test to check if your true e-mail address is hidden from someone sending you e-mails through your SG alias, you have to reply to the aliased e-mail and then look at what that reply message has in its headers.