I tried to send an e-mail using an alias generated by Spamgroumet (SG). I logged into spamgourmet.com, 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>+<sgacct>+<hash>.<user>#<domain>@spamgourmet.com
<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.
The:
mailto:+<keyword>+<sgacct>+<hash>.<user>#<domain>@spamgourmet.com
link when clicked on gets truncated to:
+<keyword>+<sgacct>+<hash>.<user>
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:
+<keyword>+<sgacct>+<hash>.<user>#<domain>@spamgourmet.com
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>@spamgourmet.com"}{b}+<keyword>+<sgacct>+<hash>.<user>#<domain>@spamgourmet.com{/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?
----------
UPDATE
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 (smtp.live.com): [tx] RCPT TO: <*****>
2011.11.15 01:30:19 SMTP (smtp.live.com): <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>@xoxy.net
xoxy.net is one of SG's domains. The max receive count is optional. So I give a <keyword>.<sgacct>@xoxy.net 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>@spamgourmet.com
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>@spamgourmet.com
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.