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/Outlook.com 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 Outlook.com'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:
name@example.com. If you're using category names or nicknames, make sure you don't have any typos.
Possible typos:
keyword.mysgaccount.sgIDnum.senderfirst ... ob.0sg.netMicrosoft's parser doesn't think "keyword.mysgaccount.sgIDnum.senderfirstname.senderlastname#gmail.com" 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" <mykeyword.mysgaccount.sgIDnum.senderLToken#senderRToken@ob.0sg.net>
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/Outlook.com 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 Outlook.com 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.