Possible bug sending emails using disposable SG address

[vsp]

I was playing around trying to test the SG service and used the "send a message from one of your disposable addresses" link to send a test message from my real ID to another of my real IDs.

On the other account I viewed full headers and discovered that my original ID (my forwarded email ID under SG) showed up under the MIME header "X-Originating-Email".

If the idea is to hide my real email ID, then the real email ID shouldn't go out in the MIME headers either, otherwise a simple regex match would yield my real ID if the receiver were trying to harvest IDs to sell to spammers.

Do you folks agree this is a bug?

[josh]

We've covered all the standard headers, and some non-standard ones:

Code: Select all

    $message =~ s/(^Return-Path\: ).*$/$1 $sender/mi;
    $message =~ s/(^From\: ).*$/$1 $sender/mi;
    $message =~ s/(^Sender\: ).*$/$1 $sender/mi;
    $message =~ s/(^X-Sender\:).*$/$1 $sender/mi;
    $message =~ s/(^X-Sent-From\:).*$/$1 $sender/mi;
    $message =~ s/(^Disposition-Notification-To:).*$/$1 $sender/mi;

Each mail server can pretty much put in whatever "X" headers it wants to -- I haven't heard of "X-Originating-Email". Do you know what mail server you're using to send the message with?

[vsp]

My original ID is a Hotmail account. I am not sure what smtp server they use.

Since any server can make up whatever "X-" header they want, would it be a good idea for SG to strip the original email ID from any header it occurs in and replace it with the SG email ID? Any occurence of the original ID anywhere in the headers would defeat the purpose of SG since the original ID would be visible to the receiver of the email. (Of course if the original ID shows up in the body, we shouldn't touch it since we would be modifying the message)

I have only used regexes with Python before, and I am not familiar with the header format for SMTP messages, but I will post back with a suitable regex if I can get it right in Perl.

[vsp]

An update to the last post:

I was testing SG by sending an email to my Yahoo account from my Hotmail account. (My Hotmail account is the account I used to register for SG and it is the one I am trying to make sure stays protected in my test when I use the SG "send email using disposable address" feature)

[SysKoll]

Josh,

The problem, as you say, is that each SMTP server can put whatever it wants in the X-headers. So ùaybe we could just replace the X-Sender and X-Sent-From rules in the code with a generic one for all X-whatever headers:

Code: Select all

$message =~ s/(^X-[a-AA-Z\-]*\:).*$/$1 $sender/mi;


This would insure that the real address is removed from these X-headers.

Would there be a problem doing this?

[maratheamit]

The X-headers are not necessarily restricted to containing an email value. So we should not be carrying out the replacement for non-email headers.

[vsp]

No, but what is wrong with stripping the email value from the header and replacing it with the SG email ID.

An example:
Consider an email ID abc@xyz.com that has an SG equivalent
a.10.abc@spamgourmet.com

Now consider arbitrary headers such as
X-arbit1:Name : a , Last name : bc, email : abc@xyz.com
or
X-arbit2:<binary data> , sender:abc@xyz.com, sdfwrsdfsf
(Note that I have no idea what a valid header looks like, I just constructed these to illustrate a point)

In both cases, why can't SG just replace abc@xyz.com with a.10.abc@spamgourmet.com? They would then look like
X-arbit1:Name : a , Last name : bc, email : a.10.abc@spamgourmet.com
X-arbit2:<binary data> , sender:a.10.abc@spamgourmet.com, sdfwrsdfsf

Otherwise, the replacing the email IDs in the From, Reply-To, ... fields has very little meaning

[josh]

vsp - we'll probably be able to do what you suggest very soon. The issue has been that the code that does the substitution does not have the "real" email address in context, and so doesn't have the reference necessary to do a blanket substitution. Instead, it looks for the specified headers and replaces *whatever* is there with the disposable address. We'll be doing some refactoring soon, and we should have the context problem corrected, so we could then do a sweep of the headers (and the body for that matter, but that's scarier because it could be huge).

This still won't be perfect, though, because the MUA from which the mail was sent may be using a different from/reply-to address from the address that is specified as the "forwarding address" in the spamgourmet account -- for instance, if you use an account besides hotmail (eg pobox?) to send the test message, it might contain a different from/reply-to address from the one you have set up in hotmail (and spamgourmet). For this reason, we'll probably want to do the specific header check followed by the sweep.

I don't think this'll be too bad on server resources because, at least for the time being, messages sent back through the system aren't that frequent.

[SysKoll]

The X-headers are not necessarily restricted to containing an email value. So we should not be carrying out the replacement for non-email headers.

You're right of course. We should limit our replacement to the user's real email, not the whole field.

[rahim]

They both enable you to thwart others from creating disposable addresses for you. What's the diff. in their function?

[Guest]

Why don't you just remove all X-lines?
They are just defined as extensions of the mail header in the RFC. They are not necessary for the mail to reach it's destination, but may contain arbitrary information the mail client wants to spread.

And while we're at it:
Why not remove the Received-Lines as well?
When I played around with "reply address masking", I found this in the reply-email:
Received: (qmail 1120 invoked by uid 65534); 5 Aug 2004 14:43:46 -0000
Received: from dialin-****-***-***-***.***-ip.net (EHLO ******) (***.***.***.***)
by mail.gmx.net (mp027) with SMTP; 05 Aug 2004 16:43:46 +0200

The stars are masking "interesting" parts. It contained my machines name (after the EHLO), it's IP, the provider used to dial in.
Again these lines are not needed for the mail to reach it's destination. They just show the way the message took, which is exactly what spamgourmet wants to hide...

Regards,
myce

[myce]

Rats, I thought I were logged in. So the previous post is by me.

Regards,
myce

[josh]

We have made the change I mentioned above to do a full scan for both the account's forwarding address and the declared "from" address on the outbound message, and testing has shown this to be as effective as anyone had wanted. I've always been hesitant to do anything to the headers beyond that because of some US state laws that impose criminal penalties for changing email headers in a way that conceals the origin of the message -- it also takes us back to the original manifesto of being a spam fighting service rather than an anonymizing service. I can also say that in the very few instances where a spamgourmet user has been accused of doing bad stuff, maintaining the full headers has been a sort of "get out of conflict free" card, which is invaluable for a free service.