Page 1 of 2

Has reply e-mail address format changed for aliases?

PostPosted: Tue Nov 15, 2011 6:51 am
by VanguardLH
I tried to send an e-mail using an alias generated by Spamgroumet (SG). I logged into, went under an existing alias (which meant someone already used it) because I couldn't find this function separately, and opted to generate a new e-mail using an alias that I created right then.

I pick an alias (that's already been used since I can't pick one that hasn't been used yet) and under its properties I click on the "click here to send a message from this address" link. That shows a form where I can enter the keyword, receive count, which SG domain to use in the alias, and the recipient's e-mail address. When I click the ok button, it creates an e-mail address that looks like:


<keyword> was a string that I provided (i.e., the alias in my SG account). <sgacct> is my SG account username. <hash> is some random string added by SG. <user> is the username in the recipient's e-mail address. <domain> is the recipient's domain in their e-mail address. SG uses this syntax to differentiate between the alias portion and the recipient's e-mail address.

The problems is the use of the pound character (#) screws up parsing in Outlook 2003. After entering the recipient's e-mail address, a keyword, and optional receive count, SG generates the alias. It shows it to me as a mailto link so I can just click on it to load it into my default e-mail client. The problem is that everything beyond and including the pound character ("#") gets stripped. Is the pound character a legitimate character in an e-mail address? Outlook doesn't think to think so. I suspect it is seen as an anchor tag in an HTML page (SG's page) rather than part of the mailto string. Whatever the cause, I have to manually copy the entire string to then copy it into the To field in Outlook.



link when clicked on gets truncated to:


in Outlook in its new-mail compose window. Maybe the pound character is okay in the username (left-id token) of an e-mail address but it isn't valid in a mailto: link - when presented in an HTML web page.

The text in the web page shows:


but is a link whose HTML code is (angle brackets were changed to braces since I don't know if this forum permits embedded HTML within posts):

{a href="mailto:+<keyword>+<sgacct>+<hash>.<user>#<domain>"}{b}+<keyword>+<sgacct>+<hash>.<user>#<domain>{/b}{/a}

Per RFC 2368, I suspect SG forgot to encode the pound character. Instead of using "#", they should use "%23". The % means an encoded character followed by its hex ASCII value. That's how, for example, to include spaces in the path/parameter portion of a URL. The # in the href attribute in the A tag is probably getting interpreted as an anchor tag name.

mailto:<string>#<string> works as a link on the Windows desktop because it's not within the context of an HTML web page. This doesn't work in the mailto link shown by SG after generating the alias because (as a guess) it might be an HTML parsing or mal-coding problem.

Has anyone used this SG feature of creating a new alias to send a new e-mail out from SG (not as a reply to an alias that someone else used to send you e-mail) and gotten their mailto link to work without truncating at the # character?



Okay, so one problem is the HTML code for the mailto link having the # character in it instead of the encode value (%23). Looks like another problem emerged: invalid syntax for reply e-mail address.

For the last couple of weeks, if I reply to an e-mail sent through an SG alias, there is an immediate rejection by the SMTP server. This happens whether it is using my ISP's (Comcast) SMTP mail server or Hotmail's SMTP mail server. The rejection is immediate during the mail session between my e-mail client (Outlook 2003) and their SMTP mail server. This is not an NDR from my SMTP server connecting to the destination's SMTP server and getting an error at the destination SMTP server. My SMTP server isn't even trying to send the e-mail because it is immediately rejecting the e-mail string in the RCPT TO command sent by my e-mail client to my sending SMTP mail server.

What I see in the e-mail client's logfile is:

2011.11.15 01:30:19 SMTP ( [tx] RCPT TO: <*****>
2011.11.15 01:30:19 SMTP ( <rx> 501 5.5.4 Invalid Email address

The asterisked value is the recipient's e-mail address. That e-mail address is the one provided by SG when it passes an e-mail through an alias. For example, I may have an alias defined at SG that looks like:

<keyword>.[<count>.]<sgacct> is one of SG's domains. The max receive count is optional. So I give a <keyword>.<sgacct> alias to someone. They send me an e-mail using that alias. It gets delivered to me. The From header that SG added has:

From: +<keyword>+<mysgacct>+<sghash>.<senderusername>#<senderdomain>

So when I try to reply to this aliased e-mail, my e-mail client's will be sending the following command:

RCPT TO: +<keyword>+<mysgacct>+<sghash>.<senderusername>#<senderdomain>

Right after my client issues its RCPT TO command with that value, the SMTP server rejects it with a 501 error. To the SMTP mail server, the value for the RCPT TO command has invalid syntax.

Did SG recently change the syntax they use to compile the reply-to e-mail address they put in the From header for e-mails delivered through their aliasing service? I know that I've had this problem for maybe a couple weeks where I cannot reply to e-mails aliased through SG because the SMTP server doesn't like the syntax for the e-mail address provided by SG in the From header (and then used in the To header which is the value used in the RCPT TO command). The problem might be older because I may not have been replying to aliased e-mails until recently.

The SMTP servers don't like the syntax used by SG for the reply-to e-mail address specified in their From header they add to e-mails aliased through their service. So I can receive aliased e-mails but I cannot reply to them using SG's e-mail address they put in the From header.

PostPosted: Tue Nov 15, 2011 10:28 pm
by josh
Nothing's changed here for years - I tried replacing the # with %23 in the code, but my browser (chrome) chooses to show the %23 instead of the #. Bluch. I'll keep picking at it.

I'm pretty sure that the redirection address format (+blah+blah, etc.) is RFC compliant, and if a server doesn't accept it, then the server's not.

PostPosted: Tue Nov 15, 2011 11:02 pm
by VanguardLH
Actually the SMTP server isn't even involved yet. When I click on the link (in Internet Explorer 8 on Windows XP Pro SP-3) shown by the SG page after it created the alias (i.e., the mailto: link with the new alias), it shows truncated in Outlook's new-mail compose window. I haven't sent the e-mail to try using the e-mail alias. That won't work since there's no domain in that alias that got copied into Outlook. It's what gets copied to Outlook that gets truncated.

I used a simplified web page that merely contained the following HTML code:

<a href="">new alias</a>

When I click on the "new alias" link, Outlook opens its new e-mail compose window but the To field only has "+keyword+mysgacct+sghash.username". Everything from and including the # character got truncated.

When I instead use %23 instead of #, as in the following HTML code:

<a href="">new alias</a>

Clicking on "new alias" gives me the FULL e-mail address in the To field of Outlook. You don't use the encoding (%23 instead of #) in the comment area of the <A> tag. You use the encoding in the actual URL which is the value for the href attribute.

If you want to show the complete e-mail address in the comment field, you would still use the # in that part. You replace it in the URL which is the href value, as in the following HTML code:

<a href=""></a>

You might be using a variable to store the e-mail string and then using it both as the value for the href attribute along with using it again for the comment section of the <A> tag. That won't work since the URL has to use the encoded values for special characters, like pound and space. You'll need to add a function to process the URL string to either convert the encoded characters to their text counterparts and use that in the comment section or convert the special characters to their encoded equivalents and use that in the URL in the href. Alternatively, you could use 2 string vars: one before the pound, another for after the pound. Then you concatenate the vars where you do string1 + "%23" + string2 for the href value and string1 + "#" + string2 for the comment.

PostPosted: Tue Nov 15, 2011 11:09 pm
by VanguardLH
As to the problem with the SMTP server rejecting the SG alias e-mail string, I'm still working on it. When I use port 25 (non-SSL) to connect to my ISP's SMTP server, it accepts the e-mail address specified in the RCPT TO command sent by my local e-mail client. When I use port 587 (SSL), my client connects to their server, logs in okay, and then immediately issues a 501 error on the RCPT TO command from my e-mail client. This only happens when trying to send e-mails that are replies to those received through an SG alias but only when SSL is used.

Port 25 (non-SSL) works with the SG reply alias. So I don't know why they have a problem parsing the RCPT TO value (SG's reply alias) when using port 587 (SSL). It's not a connection problem since that's already established to then do the login which also succeeds. For some reason, it appears they have a problem with SSL traffic, the RCPT TO value, and the SG reply alias used for that value. Go figure.

I've talked to my ISP and claim not to support SSL on port 587 although they told me to move from 25 to 587 a couple years ago and also told me that I could use SSL on 587. It's been working for over a couple years with that setup (587+SSL). Now they say they don't support SSL on 587 and I need to use 465. So I'll be doing testing on port 465+SSL.

PostPosted: Wed Nov 16, 2011 7:42 am
by VanguardLH
Well, I've got SG reply aliases to work with my ISP's SMTP server by changing ports (587 to 465 with SSL). Don't know why that matters. The connection on 587+SSL was accepted, the login credentials were accepted, but it didn't like the e-mail address for the recipient in the RCPT TO command. When I changed to 465+SSL, their server now accepts the SG reply alias. So that problem was fixed but that was a test case using another SMTP server.

My SG account points to my Hotmail account, not to my ISP's account. I still cannot get Hotmail to accept the SG reply alias. I checked my setup in my e-mail client against the instructions at ... 72406b3fb7. What I was using is still what they say to use. If I try not using SSL (on ports 25 or 587), an error tells me that their server expects a StartTLS to establish a mail session; i.e., I must use SSL to use the Hotmail server. Hotmail still issues a 501 error on the RCPT TO command with SG's reply alias as its value. Since my SG account points to my Hotmail account and Hotmail still rejects the SG reply alias, I cannot reply to e-mails using my Hotmail account that were sent through an SG alias to my Hotmail account.

I don't reply to all SG aliases that I give out. Some are for newsletters or flyers and don't/won't accept replies. It's only within the last couple of weeks where I used an SG alias in a Craigslist ad where I found that I couldn't reply using the SG reply alias.

Since SG hasn't changed their syntax for their reply alias, maybe Hotmail and some other SMTP servers have changed their parsing on the RCPT TO command. If josh (the only respondent so far to this thread) can do a test by using his Hotmail account or just creating a new temp Hotmail account for testing, I'd like him to send an e-mail to his Hotmail account using an SG alias and then try to reply to the SG reply alias put in the From header. Don't use the webmail client (i.e., the Hotmail site) since that may not use proper SMTP commands to submit an e-mail into the outbound queue. The Hotmail account needs to be monitored with a local e-mail client that will issue a RCPT TO command with the SG reply alias to Hotmail's SMTP server.

--- UPDATE ---

Figuring there may be a problem in Outlook regarding the value it puts into the RCPT TO command issued to the SMTP server that causes the 501 error when using an SG reply alias, I went to the Hotmail webmail client (the Hotmail web page) and tried sending an e-mail using their web form. I composed a new e-mail using their webmail client and enter the SG reply alias into the To field. When I clicked the Send link, their webmail client refused to send the test e-mail. Instead it reported that the syntax for the e-mail address in the To field was invalid.

So it's not a problem with Outlook 2003, using an SG reply alias, and Hotmail's SMTP server that generates the 501 error. Hotmail won't accept SG reply aliases anymore. So it looks like Spamgourmet will have to change its syntax for its reply aliases (those it puts into the From header for e-mails delivered through its aliases) or its users can no longer use Hotmail as the target account to which SG delivers the aliased e-mails.

(Because I found Hotmail's webmail client refuses the SG reply alias, josh doesn't need to do any testing with a test Hotmail account to see if his local e-mail client can send a reply using the SG reply alias.)

Hotmail rejects SG reply alias & invalid mailto URL

PostPosted: Mon Nov 21, 2011 9:27 pm
by VanguardLH
Okay, I'll summarize the problems I've reported above.

SG reply alias rejected by Hotmail

After working with my ISP to fix parsing by their SMTP server, the SG reply alias is no longer rejected during the RCPT TO command. The SG reply alias also works when using Gmail to send the outbound e-mail using that SG reply alias.

Hotmail still rejects SG's reply alias (what's in the From header for an inbound e-mail forwarded through an SG alias). This may be new but I don't often reply so I cannot say when Hotmail changed their parsing that now rejects SG reply aliases.

This means I cannot have SG aliases pointing at my Hotmail account unless I want only 1-way (inbound only) communication using those aliases. If I attempt to reply (using my Hotmail account), the SG reply alias in the From header used in the RCPT TO command to identify the recipient of my reply will get rejected by Hotmail. This is not just an issue with their SMTP server's parsing of the RCPT TO value. Their webmail interface ( will also reject the SG reply alias when entered into the To field of a new outbound e-mail. SG users cannot reply to aliased e-mails when using a Hotmail account.

Wrong URL syntax for mailto link

RFC 2368 - mailto URL scheme
Section 2: Syntax of mailto URL
Note that all URL reserved characters in "to" must be encoded: in particular, parentheses, commas, and the percent sign ("%"), which commonly occur in the "mailbox" syntax.

The # (pound character) is not explicitly mentioned but then most of the URL reserved characters are not mentioned. See: ... coding.htm

Parsing in HTML can be confused by inserting an anchor reference within a URL. To HTML parsers, looks like a reference to an anchor named recipientdomain. A URL parsed from HTML code would see:

<a href="">...</a>

as a mailto URL of:


and an anchor reference (which likely doesn't exist in the web page) of:


What you show in a text string doesn't necessarily work when used as the URL string. Some characters must encoded for use within a URL.


  • Hotmail cannot be used as the target account for SG aliases because Hotmail will reject SG's reply alias. Hotmail users cannot reply to e-mails redirected through an SG alias.
  • The mailto URL needs the # encoded as %23. The comment or text string (between the <a> and </a> opening/closing tags) should show the # character.
Because Hotmail now rejects SG reply aliases, and because I see no action yet taken to resolve this issue, I'll have to contrive a different setup with SG that uses a different e-mail provider. While the mailto URL problem is just a nuisance (as a workaround the user can copy and paste the text shown in the web page), the problem at Hotmail makes it unusable to reply to aliased e-mails sent through Spamgourmet.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Fri Apr 05, 2013 3:42 am
by VanguardLH
I have been using my ISP's e-mail services since reporting this problem so I forgot all about it. Since last time I moved from one residence to another caused me to lose my ISP's e-mail accounts for my e-mail addresses, I decided it was time to start planning on moving away from my current ISP's e-mail services. I picked Microsoft's Hotmail/Live/ services because of the Deltasync feature that lets me synchronize e-mail, calendar, and contacts. That way, when I'm away from my home computer, I can still have access to my e-mails, calendar, and contacts via their webmail client.

Alas, I ran into this really old defect with Spamgourmet. I couldn't sent replies through Outlook (with the Outlook Hotmail Connector which adds Deltasync support) or with Windows Live Mail (WLM) 2011 (also with Deltasync support) to e-mails delivered through a Spamgourmet alias. Logging in Outlook was worthless (doesn't show the handshaking of the Deltasync protocol) and error messages in WLM were too vague. So I decided to perform a Reply by using's webmail cilent. Sure enough, it didn't take long to find the cause of the problem.

When I tried to reply to an e-mail delivered through a Spamgourmet alias, and which has all sorts of parsing characters that Spamgourmet likes to use to figure out in a reply as to whom the reply gets sent, Microsoft highlights the "To" e-mail address in red and displays "This address may not be valid" when the mouse is hovered over it. So Microsoft doesn't like all those parsing characters that Spamgourmet adds in the Reply-To header. If I try to send the e-mail despite Microsoft's warning of a possible invalid e-mail address (to the recipient to whom I'm replying to their Spamgourmet aliased e-mail), I get:

Please use the following format for email addresses: If you're using category names or nicknames, make sure you don't have any typos.
Possible typos: keyword.mysgaccount.sgIDnum.senderfirst ...

Microsoft's parser doesn't think "" is a valid "name" in an e-mail address. When an aliased e-mail is delivered through Spamgourmet, the From header contains:

From: "sendername - senderLToken@senderRToken" <>

The comment field in the from header was changed from just their name to also showing their e-mail address. The e-mail address (to which a reply is sent) has my keyword (what I give the sender to use), my Spamgourmet account name, a number string added by Spamgourmet to identify the alias, and the sender's e-mail address (but with "@" replaced with "#"). Some possible reasons why Microsoft thinks this is an invalid e-mail address could be:

- Inclusion of the sender's e-mail address in the comment field might trigger Microsoft to think you are specifying more than one e-mail address or that there is a mismatch between the e-mail string within the comment to the e-mail string enclosed within the angle brackets. The e-mail addresses -- two of them -- shown in the e-mail string do not match. Why does the e-mail address even show up in the comment field in a received e-mail aliased through Spamgourmet? I'm pretty sure the sender didn't put their e-mail address in the comment field. Only Spamgourmet does that.

- Left token in recipient's email address is too long. In a particular case, the "mykeyword.mysgaccount.sgIDnum.senderLToken#senderRToken" was 56 characters long. With Spamgourmet, the keyword, text-based optional count parameter, and account name can each be 20 characters in length so that could be up to 63 characters with the period characters to start with (20+1+20+1+20). Now consider if you also permited normal e-mail addresses to have a similarly long left token (username) in an e-mail address. That means the left token for the recipient's e-mail address could be over 120 characters in length. I'm sure some parsers for some e-mail providers won't go that high and might end up truncating the string. This doesn't look to be the problem at Hotmail. Looks like Hotmail doesn't like the "look" of the aliased reply e-mail address.

- Too many "special" characters in the left token of the recipient's e-mail address. There are a total of 5 periods (3 by Spamgourmet and 2 in the recipient's e-mail address: fname.lname@domain.tld) and 1 pound sign. I have used other e-mail providers in the past who thought there was some maximum count of period characters in the left token of an e-mail address (so I couldn't use more than 2 or 3).

- Maybe Microsoft doesn't like Spamgourmet's domain(s) and is blocking sending e-mails through that service.

Whatever the cause, and because this is a really old problem in trying to reply to e-mails when using Hotmail/Live/ accounts that were aliased through Spamgourmet, it's not a problem that I expect is going to get addressed by Spamgourmet. It's an old problem and Spamgourmet is still behaving the same way in its construction of the left token in the recipient's e-mail address. I've looked at other non-ISP e-mail providers with Microsoft and Google coming out on top except Google doesn't have some nice features available in Hotmail (e.g., exclusive mode, better and more intelligible filters, synchronization with Outlook or WLM as a local or desktop e-mail client, etc). I'll be moving to Hotmail (using the new domain). That pretty much means using Spamgourmet is bust. I cannot use Spamgourmet to reply to e-mails aliased through Spamgourmet.

Using Spamgourmet with my ISP's e-mail service (but only after I got them to fix their parser, as noted before) was great. It was fun and very useful while it lasted. Because I'm moving to Hotmail as my e-mail provider, and because it won't accept the left-token in e-mail addresses when replying to aliased e-mails sent through Spamgourmet, I'll have to find something else to protect my true e-mail addresses. It was good while it lasted.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Fri Apr 05, 2013 4:24 am
by VanguardLH
Just to add (since I know this will come as a counter argument), relying on RFC standards as to what characaters are permitted in the left and right tokens of an e-mail address does not eliminate problems in parsing email addresses. Yahoo Mail, for example, uses the inane scheme of prepending an alias to an existing username, like Yeah, like that really hides the true e-mail address from someone else. The problem is not all e-mail providers allow the plus sign as a valid character in the left token of an e-mail address. They may only permit A-Z, 0-9, dot, and hypen. Yeah, pound, parenthesis, exclamation point, and other non-alphabetic characters are permitted in the RFCs but just who do you know that complies with all RFCs?

So that Microsoft isn't permitting an RFC-compliant e-mail addresses doesn't mean they're "wrong". It just means Spamgourmet is generating RFC-compliant strings that aren't guaranteed to be properly handled by Microsoft or other e-mail providers. Getting too "weird" in the syntax means Spamgourmet WILL run afoul of parsers and syntax validators at many e-mail providers. I've seen some that use PHP scripts to validate e-mail strings and they are far from supporting all RFC-permitted characters in e-mail addresses.

My opinion is that I see Spamgourmet is disinterested in making that service work with Hotmail/Live/ accounts. This is over a 2-year old reported problem and it still exists, so it's not going to get fixed. Spamgourmet might take the attitude that "we're right and damn everyone else, including really big e-mail providers". What other *free* e-mail providers come close to the number of users for Hotmail, Gmail, and Yahoo? Even if Gmail and Yahoo are currently accepting the syntax of Spamgourmet's reply-to e-mail address, that's no reason to ignore the third biggest e-mail provider (Hotmail).

Re: Has reply e-mail address format changed for aliases?

PostPosted: Fri Apr 05, 2013 3:03 pm
by josh
VanguardLX - in response to the complaints, we re-engineered the system to stop using plus signs. That was a fairly major undertaking. We are still using the # mark. This is, of course, RFC compliant (as are + signs), but also is something that has been used in practice for mail relay agents, although perhaps not for some time. As a matter of practice, the # sign has not been used in true local-parts, perhaps so that it could be used by relay agents as we're doing. As to the number of dots, doesn't that seem wildly non-deterministic to you?

We can't keep overhauling our code to comply with the whims of this/that/the-other email service whose developers didn't read the RFC. This is not a "defect" in spamgourmet (nor was it before the last change).

Please note that it's not a trivial technical problem to allow replies and outbound messages from disposable email addresses. I'm not aware of any other disposable email address services that allow you to do it (not that there aren't any - but I haven't seen them). In order to make it work with the limited computer resources we have, I don't see another way than to heavily overload the [local part] of the redirection address, and in order to make that work without creating other problems, there's going to have to be complexity - there's a fairly large amount of information squashed into that local part, not the least of which is an anti-abuse scheme that must be in place.

So, don't know what to tell you.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Sat Apr 06, 2013 9:00 pm
by VanguardLH
I realize changing the parsing code (what Spamgourmet uses to contruct their alias along with the masking used in the From or Reply-To headers to have replies to aliased e-mails go back through Spamgourmet) is not trivial. I also realize that Spamgourmet complying with the RFC standards on what characters are permitted in the left token of an e-mail address doesn't mean all e-mail providers will accept that syntax. There are some rather wildly unexpected non-alphanumeric characters that the RFCs permit.

For now, the only way that I can continue using Spamgourmet with it forwarding aliased e-mails to Hotmail/Live/ accounts is to disable the "reply masking" option in my SG accounts. Then the e-mail address in the From or Reply-To headers will be the sender's true e-mail address and not one that has been massaged by SG (to make replies go back through SG). Replies will go directly to the sender which means my true e-mail address will get revealed.

That defeats half the protection afforded by Spamgourmet. Where I before could use aliases to protect my true e-mail address and also have my replies hide my true e-mail address, I can only use aliases to hide my e-mail address from a sender unless I reply to them. So I can still kill an alias (set its max use count to zero) to eliminate further e-mails through it but I will be exposed should I reply. Some e-mail clients (none of which I'm interested) let me alter the From header (so I could specify my SG alias); however, those also add a "behalf" header that shows my reply came From my alias but reveals it was sent on behalf of my real account. Only if the recipient doesn't look in the headers would they only see what I put into the modified From header.

With Microsoft Hotmail/Live/ accounts, half of Spamgourmet's services are still viable: using aliases to hide my true e-mail address (but only on incoming messages). Reply masking has to be disabled to replies go directly from my to the other party. This reduces Spamgourmet to an e-mail forwarding service. There remains some value to using Spamgourmet but reply masking is lost.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Tue Jan 21, 2014 10:43 am
by VanguardLH
Well, I moved away from my ISP so now have to use a free e-mail provider (so I don't lose my e-mail address again with another ISP and should I eventually have to move away from them). I dislike Gmail because its filters (rules) suck and Google doesn't really understand POP or IMAP protocols (they have their own modified version which can cause problems with some client setups). Yahoo doesn't provide POP access for free accounts (that are not contracted with an ISP to do e-mail services). I'm using Hotmail now.

Spamgourmet managed a coup in getting Craigslist to use Spamgourmet's aliasing service to help protect buyers and sellers there. However, with Hotmail having perhaps a third, or more, of the market for free e-mail services, that means Craigslist users with Hotmail addresses (especially sellers) will not be able to reply to SG aliased e-mails. That is, sellers using Craigslist's aliasing service (provided by Spamgourmet) won't be able to reply to potential buyers who send them inquiries about their Craigslist ads. That's a lot of Craigslist users that will be unhappy that Craigslist's aliasing scheme (via Spamgourmet) is unusable to them. I am just one Hotmail user that found SG aliases won't work to hide my true e-mail address (unless I disable SG's reply masking function but that means revealing my true e-mail address in replies). Now all Craigslist sellers that have Hotmail e-mail addresses are going to have the same problem as me.

Spamgourmet's argument is that the pound character ("#") is valid in the left token of an e-mail address, and so it is per RFC. So what? That same argument can be used by anyone to include that same character in their regular (non-aliased) e-mail address. If it isn't invalid for SG to use "#" in the left token of an e-mail address then it is also not invalid for anyone ELSE to use the "#" in the left token (username) of their e-mail address. So how is SG going to parse out the sender's e-mail address (the recipient in a reply for the SG user) when the sender also uses the "#" character?

Say a sender's e-mail address is "fname#lname@domain.tld". They send an e-mail to an SG alias. The SG user will get an e-mail whose From header contains:


For as many "#" characters in the sender's e-mail address, there will be N+1 of them in SG's reply value. Remember that "#" is a legit left token character per RFC and Spamgourmet's claim to let them use that character. How is SG going to parse an e-mail address with multiple "#" characters? There is no legit character that SG can use in the left token of an e-mail address that a sender cannot also use (if only using RFCs to qualify usage). Maybe SG can parse starting from the right end of the string to find the rightmost "#" character; however, how does SG then determine in that right-to-left parsing when a period character (or the "+" used before) belongs to the left token of the sender's e-mail address or delimits the sghash field?

Since no character that SG can use in the reply e-mail address cannot also be used by a sender in their e-mail address, parsing will remain a problem at SG. While Hotmail rejects SG's reply e-mail address (with the "#" character before the "@"), most e-mail providers that I've used always had some limitations as to what characters they will support in an e-mail address. Typically a-z, 0-9, period, dash, and underline being acceptable in the left token and all other characters were unacceptable. Whatever the RFCs permit doesn't obviate the LCD (lowest common denominator) used in practice by e-mail providers. They need some means of parsing the string, too. That nothing SG can use cannot also be used in a sender's own e-mail address which could cause parsing problems for SG shows the fragility of relying on the sender's e-mail address (the recipient in a reply to an SG-aliased e-mail) to be contained in the e-mail string.

Spamgourmet already must implement a database since something like it must be used to track which aliases are shown as used in my SG account, when an e-mail came through an alias, and how many uses remain on that alias. So why not also record (per alias already tracked by SG) the sender's e-mail address, like an index in the record for an alias? SG is already somehow tracking the aliases probably with a database. For each alias, also record each sender that used that alias. Each sender would have an index value, like the first sender being added as a "1:<senderemail>" record assigned to the alias, the second sender added as "2:<senderemail>" record assigned to that alias. Adding fields is more hairy than associating additional records to a parent record, so each sender would generate another record in the database that has a field associating it to the record recording information on an alias. Then when a sender sends their e-mail through an SG alias, the reply e-mail address seen by the SG user might look like "<keyword>.<sghash>.<sgindex>@<sghost>". The SG reply address doesn't include the recipient's e-mail address. The reply has to go back through SG's servers, anyway, so go lookup the indexed sender in SG's database at the SG server to figure out where to send that reply. The sghash must already be something recorded in SG's database to know what alias is referenced. So add an index to the hash to show which affiliated record stores the sender's e-mail address. Expand what gets recorded in SG's database so the sender is known there rather than having to shove it into the reply e-mail address. Yes, this would require a big rewrite to SG to use a database-referencing record (for the alias) along with an indexing (for the sender-email records associated with the alias record) but if Spamgourmet is going to partner with large companies to provide an aliasing service then SG needs to consider that a significant number of customers of its partner(s) could be Hotmail users.

I'll have to check with Craigslist if their Hotmail users (mostly affecting their sellers) are having problems there when using Craigslist's aliasing feature which was switched over to using Spamgourmet to handle the aliasing service; however, I rarely ever get a response from Craigslist (in fact, I can't remember ever getting a reply from them).

NOTE: I have seen no declaration from Craigslist that they use Spamgourmet for their aliasing service. What Craigslist used before was weak and provided only 1-way protection (buyer to seller but not when seller replied). What Craigslist switched to sure looks like Spamgourmet's aliasing service. As I recall, when looking at the domain in the reply-to e-mail address, it was for a SG domain. Or maybe the scheme they describe and the e-mail strings used by them are so identical to Spamgourmet's that it seems unlikely a coincidence.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Thu Jan 23, 2014 6:00 am
by VanguardLH
Well, it's gotten worse. I could use Spamgourmet as a 1-way aliasing service. I could dole out an alias to a sender but had to disable reply masking in SG because Hotmail (and I'm sure others) reject the "#" in the left token of the reply-to e-mail address. Previously I could get e-mails delivered that were sent to the SG alias. No longer.

As a test, I sent an email from my Gmail account to a new SG alias. It never arrived at my Hotmail account. I noticed the alias got generated at SG so Gmail's SMTP server connected okay with SG's SMTP server to transfer the message. SG generated the alias but from that point I can't tell what happened because there are no SMTP logs accessible by the user to see what happened during the mail session between SG and Hotmail.

No, the aliased e-mail is not in the Junk/Spam, Trash, or any other folder. It never arrived to my account to get deposited into any folder. So there was some error during the SMTP session between SG and Hotmail. That means I no longer get any incoming e-mails at Hotmail that came through SG using an alias. So I cannot reply to SG-aliased e-mails that [used to] arrive at my Hotmail account and now I cannot receive SG-aliased e-mails at my Hotmail account.

With Hotmail, SG is completely unusable. Can't reply and now cannot receive.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Mon Feb 17, 2014 2:32 am
by VanguardLH
And it gets even worse. Despite SG's author/owner saying it is just Hotmail that is belligerent in their parser not accepting "#" in the left token, so does Gmail and Yahoo Mail. That is, using SG's current reply masking scheme where the "#" is used in the left token of the reply-to e-mail address, all of the major free e-mail providers - Hotmail, Gmail, and Yahoo - will refuse to accept it as a valid e-mail address when attempting to send a reply e-mail. I have tried several other free e-mail providers and they, too, will not accept the "#" in the left token of the e-mail address specified in the Reply-To header added by SG when using its reply masking feature (which allows replies to be masked by going back through SG). So the Big 3 along with lesser free e-mail providers cannot be used as the destination for SG aliased e-mails.

SG has chosen to stand alone regarding its claim that the "#" is a legitimate RFC-valid character in the left token while ignoring that it causes parsing errors at many free and paid e-mail providers, including the biggest ones. SG parsing does not need to use the "#", especially if right-to-left parsing were used to extract the components needed by SG to track through which account to process a reply. Other aliasing services don't need to use "#" or any special character outside the alphanumeric, 0-9, underscore, dash, and period characters. Positional notation is sufficient to parse the components of the left token.

To other users, good luck in finding an e-mail provider who will accept the "#" in the left token (username) portion of the e-mail address SG injects into the Reply-To header when using SG's reply masking feature (which has your replies in your destination account go back through SG to ensure your reply remains aliased to hide your true e-mail address). For me, the number of e-mail providers that I have found that will accept the "#" in the left token is too few and makes SG too limited as to where I can use it. After awhile I managed to get my ISP (Comcast) to change their parser but expect far less than stellar response from other e-mail providers, especially the free providers that don't offer support. Since I'll be moving away from my current ISP, I won't be able to take advantage of their modification to get SG replies to work with them. Alternatively, you could disable reply masking in SG and then use a local client that lets you specify the value for the From header in your replies. Then you could compose a reply and have the From header point at the alias through which you received the aliased e-mail. You could use SG as just another of the many e-mail forwarding services and let your replies reveal your true e-mail address. Lastly, your could move to another aliasing service that doesn't use "#" or other irregular characters in the left token they use in the Reply-To header for aliased e-mails; e.g., Sneakemail, SpamEx (alas the only reliable alternatives to SG are paid services since SpamMotel, and other free aliasing services are flaky, ill-supported, slow, or have disappeared).

Re: Has reply e-mail address format changed for aliases?

PostPosted: Wed Feb 19, 2014 8:40 pm
by ragingdragon
Vanguard: Are you aware of a concept called brevity? Having multiple thousand word posts does not make it easy to read. Kudos to josh for actually getting through them.

Re: Has reply e-mail address format changed for aliases?

PostPosted: Fri Feb 21, 2014 3:50 pm
by josh
I use gmail and reply address masking with the # all the time.