Real email address is NOT protected

General discussion re sg.

Real email address is NOT protected

Postby theunbob » Sat Apr 20, 2013 9:07 pm

Shocking but true! My real email address was obtained from the SG web site by another web site.

I registered on the ISOhunt web site - https://isohunt.com - using a SG "disposable" email address. I do this all the time when registering on various web sites.

This time however was different. The assigned username I was given was actually my "protected" real email address (the one I specified to SG as my forwarding address)!

Here's the details - when registering on the ISOhunt web site I entered "isohunt.myname@spamgourmet.com' for the requested email address (where "myname" was replaced with my actual SG username). The email I received from ISOhunt stated:

Your account information is as follows:
----------------------------
Username: myname@email.com
Password: U8Lt52xFR8S


Where "myname@email.com" is my actual SG "protected" real email address! The "From" address on the email message indicated that it was processed and forwarded by SG.

This is very disturbing to say the least. Has any other SG user experienced this problem? And, by all means, feel free to try this for yourself to confirm what I'm saying is true.

Much appreciate any and all feedback. Thx, Rob
theunbob
 
Posts: 6
Joined: Sat Apr 20, 2013 8:23 pm

Re: Real email address is NOT protected

Postby josh » Mon Apr 22, 2013 1:48 am

that does sound scary - I'll try to sign up - I just tried, but it says "Servers are down partially, reason: db maint. Please come back to this link a bit later."
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Re: Real email address is NOT protected

Postby theunbob » Mon Apr 22, 2013 1:57 am

josh wrote:that does sound scary - I'll try to sign up
Thank you Josh. Yes, please try to sign-up on ISOhunt. I'm anxious to see if you have the same result.
theunbob
 
Posts: 6
Joined: Sat Apr 20, 2013 8:23 pm

Re: Real email address is NOT protected

Postby josh » Tue Apr 23, 2013 7:17 pm

Here's what I got:

Welcome to isoHunt Forums

Please keep this email for your records. Your account information is as follows:

----------------------------
Username: tstisht
Password: *********
----------------------------

Your account is currently inactive. You cannot use it until you visit the following link:
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Re: Real email address is NOT protected

Postby josh » Tue Apr 23, 2013 7:17 pm

that's the username I provided, by the way.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Re: Real email address is NOT protected

Postby theunbob » Tue Apr 23, 2013 7:52 pm

Interesting. Is the username you specified to ISOhunt identical to the local part (before the @ sign) of the SG protected address? Mine was identical. In other words, if my SG protected address is "fred@gmail.com" - I specified "fred" as my ISOhunt username.

Whether identical or not, the complete SG protected address should not be obtainable - period.
theunbob
 
Posts: 6
Joined: Sat Apr 20, 2013 8:23 pm

bounces

Postby Jim27106 » Wed May 01, 2013 2:21 am

What would happen if they sent a message that would bounce. (perhaps too big.) Would that cause a real address to be revealed? I don't want to do the experiment because I don't want to hit SG with a huge email to process.
Jim27106
 
Posts: 92
Joined: Sun Mar 05, 2006 8:07 am

Re: Real email address is NOT protected

Postby ragingdragon » Mon May 06, 2013 9:33 pm

I tried to sign up here for an account that shared the first part with my protected email address. However, I did not see my real email address anywhere. However, what I did see was that there was a section where it specified a message similar "received by sg.com for user@gmail.com", in the message headers. I think that for some reason if a message were to bounce, the sender might be able to get hold of the protected address though I thought sg.com doesnt bounce anything by design. Josh, this is probably something that would be better for you to test than for us to try and load the server unnecessarily. I would happily do it if u give the go-ahead though!
ragingdragon
 
Posts: 23
Joined: Thu Apr 11, 2013 5:25 am

Re: Real email address is NOT protected

Postby josh » Tue May 07, 2013 7:57 pm

if it's a bounce that comes back *through* spamgourmet - that is, the user has address masking turned on, then our code looks for instances of the forwarding address and replaces them with the disposable address. If the bounce goes straight from the user's end server back to the sender, then there's nothing we can do about it.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Re: Real email address is NOT protected

Postby VanguardLH » Fri May 17, 2013 3:43 am

Just stopping by (while considering whether or not to post my problem here) and read this thread. I have to wonder if you are using a UNIQUE password at every site you visit, even those where you dole out an SG alias. After all, anyone can read the help here to understand how aliases are constructed for use here. They all look like <somestrings>.<sgacct>@<sgdomain>. If you give the site the same password there for your account there that you use at SG then obviously that site knows how to log into your SG site. You told them your SG account since <sgacct> is specified in the alias. If you use your SG password at the other site then they could use it to get into your SG site.

You give them an SG alias.
It contains your SG account name (the <sgacct> part of the alias).
You use the same password at the site as you do at SG.
The site might not be [deliberately] internally secure so they can get your password with them.
They go to the SG site and try the password you gave them to get into your SG account.

The last step will succeed if you use the same password at both the SG and other site. You should really be using a unique password at every domain. Even my password at SG is unique in that it is not used anywhere else. No one at one site can use my password at any other site where I have an account. I don't even trust my own ISP with passwords (I have them do a reset rather than tell them what it is). I have an algorithm that I can remember when assigning passwords so they are unique at each domain. Some folks use software instead, like KeePass (but then they need to remember the master password to get into their Keypass database and tote around a copy of the program so they can login from anywhere). If an account gets compromised at one site, your login credentials cannot be used at any other site where you have accounts -- because your password is always different at different sites.

I'm not saying this is how it happened. I'm saying that if you use the same password at multiple sites then those sites can know what is your password at other sites. I've never visited the isoHunt forums so I cannot speak regarding how trustworthy they are with your login credentials for your account on their site. isohunt.com is hiding behind a private domain registration at GoDaddy; that is, you won't see the true registrant listed for that domain but GoDaddy assumes responsibility for IANA's requirement regarding valid contact info for domain registrations. Lots of registrars do this at an extra fee. They let their registrants hide who they are, where they are, and secrete other identifying registrant data. Ask yourself if you want to trust a site that feels the need to hide who and where they are as the registrant for a domain. Sorry, the old excuse of using privatized domain registrations to avoid getting spammed at domain registration expiration time is flimsy and usually a lie. Nothing precludes a registrant from providing an e-mail address in their domain registration that will accept e-mails only from the registrar and trash all others. Sites that hide behind privacy registrations are doing so for a negative reason, plus they have to pay extra to do that hiding. Any site that hides behind a privacy registration raises a red flag, to me, regarding their trustworthiness.
VanguardLH
 
Posts: 51
Joined: Sun Oct 11, 2009 10:01 pm

Re: Real email address is NOT protected

Postby Spamennamee » Sun Jul 21, 2013 10:42 pm

I found that - when sending a spamgourmet email originating from one of my gmails to another gmail account of mine - I could uncover the originating gmail address:

Received: from mail-vc0-f171.google.com ([209.85.220.171])
by gourmet7.spamgourmet.com with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128)
(Exim 4.80)
(envelope-from <myrealaddress89@gmail.com>)

In the recipient gmail account, I click "show original" and my "hidden" address is there, even though it was sent using spamgourmet. I don't think this has always been the case, as I've tested it occasionally and I believe origin info was hidden in the past. Now.. not so much.
Spamennamee
 
Posts: 3
Joined: Sun Jul 21, 2013 10:18 pm

Re: Real email address is NOT protected

Postby VanguardLH » Mon Jul 22, 2013 5:27 am

Spamennamee,

What happens when you send from your Gmail account to another that is OUTSIDE the gmail.com domain? The problem when testing e-mails sent within the same domain is they usually shortcut the routing process. It doesn't go to their SMTP server to get sent out. Instead it gets directly routed internally from one account to another. E-mail protocols aren't even involved. You sure that your Gmail-to-Gmail message even went outside of gmail.com (to get through your Spamgourmet account)? Many e-mail providers internally route messages between account and never involve their e-mail servers when the source and target are both users with accounts inside the same domain.

To test e-mail handling, you have to send your test e-mail to a DIFFERENT e-mail provider than the one from where you send. If you are sending from a Gmail account then the test recipient should be somewhere else, like Hotmail, Yahoo, or your ISP's e-mail service. You need to ensure your e-mail actually gets *out* from your sending server and not routed internally and directly between accounts.

Since you didn't show all the Received headers, no one can tell exactly what routing took place between the two same-domain accounts.
VanguardLH
 
Posts: 51
Joined: Sun Oct 11, 2009 10:01 pm

Re: Real email address is NOT protected

Postby Spamennamee » Mon Jul 22, 2013 10:15 am

I haven't tested routes such as gmail>hotmail or other similar routes that don't start and end in the same system. It's just that gmail is so widely used - by legit users (me) as well as spammers/scammers that I wanted to see what happened in that scenario. That being said, here is the full header on the recipient email:
Delivered-To: myothergmailacct@gmail.com
Received: by 10.220.149.77 with SMTP id s13csp32318vcv;
Sun, 21 Jul 2013 15:01:43 -0700 (PDT)
X-Received: by 10.68.217.170 with SMTP id oz10mr27629191pbc.152.1374444103302;
Sun, 21 Jul 2013 15:01:43 -0700 (PDT)
Return-Path: <>
Received: from gourmet8.spamgourmet.com (gourmet7.spamgourmet.com. [216.75.62.102])
by mx.google.com with ESMTPS id km7si16300258pbc.35.2013.07.21.15.01.42
for <myothergmailacct@gmail.com>
(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
Sun, 21 Jul 2013 15:01:43 -0700 (PDT)
Received-SPF: pass (google.com: domain of gourmet8.spamgourmet.com designates 216.75.62.102 as permitted sender) client-ip=216.75.62.102;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of gourmet8.spamgourmet.com designates 216.75.62.102 as permitted sender) smtp.mail=;
dkim=fail header.i=@gmail.com
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.80)
(envelope-from <Zeke.xyz.9.myacct@xoxy.net>)
id 1V11hG-0001Yj-BE
for myothergmailacct@gmail.com; Sun, 21 Jul 2013 22:01:42 +0000
Received: from mail-vc0-f171.google.com ([209.85.220.171])
by gourmet7.spamgourmet.com with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128)
(Exim 4.80)
(envelope-from <myrealaddress89@gmail.com>)
id 1V11hG-0001Xx-4L
for Zeke.myacct.5df6d3095c.myothergmailacct ... ob.0sg.net; Sun, 21 Jul 2013 22:01:42 +0000
Received: by mail-vc0-f171.google.com with SMTP id gd11so4383146vcb.16
for <Zeke.myacct.5df6d3095c.myothergmailacct#gmail.com@ob.0sg.net>; Sun, 21 Jul 2013 15:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:date:x-google-sender-auth:message-id:subject
:from:to:content-type;
bh=NBfDVGS0WtBXL4RL+narDaJpvzwydUaxo57zbEV0Yyw=;
b=UlUjB4RhRmH9o6kuG6sNHMphg8aPY7byrZoBCHD6/cgSAoVUzUDgfr24Fg/az3rrkq
u1jey0eyY2ptQlSPabsCo2jmYwp3l8Ko3EWZlsLc8BmQuBnCiZLCBms7C/zKz0JlXDUD
it8h7weXXJuOHy3NK2dDxrcr1ZoCoZwmXGUwWE+sfxI6jgUkp3jXibxb1iFCfL7+BPJ1
g0VWmCyXsIrISbqAr+QIiT6s9LSpFy9PF5BG/MaGby2+l0CbrpGcEarjVS1dvhVK9D7L
g7U79uZmaN12O0VzqiqGV1cRbUaRwPwktRCQ07g/bZjogDJAOMuzjT+m35wHRyPf8ilq
Vh7w==
MIME-Version: 1.0
X-Received: by 10.58.145.97 with SMTP id st1mr8516463veb.71.1374444100840;
Sun, 21 Jul 2013 15:01:40 -0700 (PDT)
Sender: Zeke.xyz.9.myacct@xoxy.net
Received: by 10.220.41.145 with HTTP; Sun, 21 Jul 2013 15:01:40 -0700 (PDT)
Date: Sun, 21 Jul 2013 18:01:40 -0400
X-Google-Sender-Auth: CFdRfrlRIbQ4hDn6zDt8odBckcw
Message-ID: <CAM8=gVkoCZoLTVQxjTANk3+tm0ULk_qtRaUhjjKCjVLSOUDNhw@mail.gmail.com>
Subject: Test
From: Zeke.xyz.9.myacct@xoxy.net
To: myothergmailacct@gmail.com
Content-Type: multipart/alternative; boundary=047d7b6768b864f12f04e20cb485

--047d7b6768b864f12f04e20cb485
Content-Type: text/plain; charset=ISO-8859-1

this is a test msg

--047d7b6768b864f12f04e20cb485
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">this is a test msg<br></div>

--047d7b6768b864f12f04e20cb485--
Spamennamee
 
Posts: 3
Joined: Sun Jul 21, 2013 10:18 pm

Re: Real email address is NOT protected

Postby VanguardLH » Mon Jul 22, 2013 8:04 pm

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/rfc5321
Section 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.
VanguardLH
 
Posts: 51
Joined: Sun Oct 11, 2009 10:01 pm

Re: Real email address is NOT protected

Postby VanguardLH » Mon Jul 22, 2013 8:05 pm

In account 1, send a test e-mail to your SG alias (redirects to account 2).
In account 2, REPLY to that aliased e-mail.
In account 1, inspect the headers in that REPLY e-mail.

Is envelope info included in SG's headers when you look at the REPLY e-mail?
VanguardLH
 
Posts: 51
Joined: Sun Oct 11, 2009 10:01 pm


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 20 guests

cron