Page 2 of 2

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

PostPosted: Wed Mar 19, 2014 4:57 am
by VanguardLH
josh wrote:I use gmail and reply address masking with the # all the time.
Yep, some mail servers will accept the # character in the left token of an e-mail address. Many won't. Even my own ISP (Comcast) rejected the # character until I requested they change their parser (and had to wait more than a year before that happened).

Code: Select all
Gmail rant

I had thought about switching my target account to Gmail for my SG accounts; however, I don't like Gmail.  You cannot set an exclusive mode where only opted in (whitelisted) senders are permitted to get e-mails into your Inbox.  Defining rules sucks in Gmail (plus you can no longer find the old web pages telling you how to define search criteria) and Gmail is pretty limp on what headers you can filter.  Negative rules rarely work.  They have no concept or decided not to embrace regex so users could define well-focused filters and eliminate false positives.  There are no stop clauses to add in their rules to prevent unwanted side effects from multiple filters exercised against the same message.  You cannot disable spam filtering which isn't needed if you could enable exclusive mode (whitelisted senders only whether by full or partial e-mail strings). 

Google has their own peculiarities in how they implement both POP and IMAP, so much so that I refer to their implementations as gPOP and gIMAP.  For example, Gmail will treat a "TOP n" command as though it was a RETR command which can screw up seeing e-mails if you use one e-mail client to only preview what is in your account (i.e., e-mail monitor) and another to actually store your e-mails (i.e., the full e-mail client).  Gmail doesn't permit message versioning so your IMAP client has its version of the e-mail shown in the Sent folder that is different than the copy put into the IMAP server's Sent folder copied from the SMTP session.  This emulates the BURL command (replaces the DATA command) that Thunderbird and most e-mail clients do not support by having the server save the message from the SMTP session to the IMAP server's Sent folder.  Having the server copy the sent message to the Sent folder is faster because download speeds for users are much faster than upload speeds.  The old IMAP scheme has the client upload the message twice, once to the SMTP server and again using IMAP to the Sent folder, and upload bandwidth is typically a fraction of download bandwidth.  IMAP with Comcast is far slower (so the mail session takes longer) because they don't emulate BURL and instead make the client upload 2 copies of the message (once to SMTP and again via IMAP) when compared to Hotmail or Gmail that do the server-side copy from the SMTP session to the IMAP Sent folder because download speed is 5 times faster than upload speed. 1x to upload to SMTP plus 1x to upload (2x total) via IMAP versus 1x to upload to SMTP and .2X to download (1.2X total) from IMAP, plus Comcast's IMAP server is slower than Hotmail's or Gmail's to further slow the response (they joy of them outsourcing their e-mail service to Zimbra).

Google using tags instead of real folders for IMAP access has its own problems.  Clients can only use 1 tag which is the IMAP folder they're told about by Gmail, but in Gmail's webmail UI you can define multiple tags for an email.  If a Gmail account has already been created that has multiple tags, which one does the client use as the folder name?  Is it in assignment order?  Is it by best-match to common folder names for real IMAP accounts?  Gmail defined a webmail client and then adapted it to POP and IMAP which weren't perfect fits in function.  Sorry, but Google sucks and being free doesn't make it suck less.

Remember that Spamgourmet is claiming # is a legit character (and it is per RFC) yet that also means any user's e-mail address could also contain that character. If it's legit for SG to use then it's legit for anyone to use as their e-mail address. So what does Spamgourmet do if the sender's e-mail address (to which you want to issue a reply through SG's alias) also used the # character? Which one will SG use to parse out their portion of the left token? If SG uses left-to-right parsing to pick the first # character as theirs to differentiate recipient's e-mail address from SG's info the left token then SG could also employ positional notation to use the first ANY character to different those sections in the left token, like using a "." (period), "-" (hyphen), or "_" (underscore) character. Pick a character that mail servers all like and can parse on and use backwards positional notation to use the first one of them as the delimiter between the recipient's address and the SG info.

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

PostPosted: Wed Mar 19, 2014 4:59 am
by VanguardLH
ragingdragon wrote: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.
You thought the problem was simple or that testing was quick and easy? If you don't want to read books or long messages, just skip them. I am well known for being verbose. You want terse. Different posters, different styles.

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

PostPosted: Wed Mar 26, 2014 5:02 pm
by josh
It's the last '#' that's used. '#' is not a valid character to use *after* the @ sign, so you can be sure the last one is the stand in for the @ sign.

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

PostPosted: Thu Mar 27, 2014 12:10 am
by VanguardLH
So something like positional notation is used to parse the left token. The rightmost (or first found when parsing right to left) "#" character is used to delimit SG's info from the return-path e-mail address. That's good as it eliminates conflict should a user have "#" in the left token of their e-mail address.

So we're back to e-mail providers whose parser will reject odd but legit characters in the left token. Most will accept alphanumeric characters along with ".", "-", and "_" but too many seem to reject "#" and other odd characters. My ISP (Comcast) rejected "#" until I submitted an RFE to get their parser changed. I don't know if they allow all RFC-compliant characters in the left token or just added "#" to a list of characters they consider valid. Microsoft (Hotmail/Live/ will reject "#" when sending e-mails, like replies to SG-aliased e-mails. Gmail rejects "#", too. If you look at Senderbase (, Hotmail and Gmail generate a lot of e-mail so they are heavily used. This isn't an example of not supporting some local yokel's e-mail service that rare few users employ. To test Yahoo Mail, I used the "send a message from one of your disposable address" feature at SG. This has the alias point to one of my valid accounts but has the # in the left token. Yahoo Mail sent the e-mail so it accepts # in the left token. Alas, I won't use Yahoo Mail because free accounts aren't granted access to their SMTP/POP/IMAP mail servers.

It's impossible to know if an e-mail provider will accept # in the left token until you have an account with them and then try to send an e-mail with # in the left token. Hotmail and Gmail are my prime e-mail providers but SG aliased e-mails won't work with them regarding replies sent back through the alias because of the # in the left token. I won't have my ISP account after I move so their willingness to change their parser will become irrelevant to use of SG. Yahoo Mail (free) doesn't have SMTP/POP/IMAP access so they're out. I will have to experiment with other free e-mail providers to see who will accept the # in the left token. Alas, in past trials, I've dumped many of the free e-mail providers because they spamified my e-mails with their signature or exhibited intolerable behavior(s).

Thanks for identifying that the last (rightmost) # gets used to delimit the SG info.

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

PostPosted: Thu Mar 27, 2014 2:48 am
by VanguardLH
I just found out that Yahoo dropped their Premium service tier for their e-mail service. It's gone. Looks to have been dropped on 04-Feb-2014. Instead they now have Yahoo Mail Ad Free for a monthly/yearly fee. Some of the Plus features are now part of those for standard (free) accounts. That includes access to their SMTP/POP/IMAP mail servers. I tested and I can use SMTP+IMAP to access a Yahoo Mail account using a local e-mail client. Yahoo Mail allows the "#" character in the left token of an e-mail address. So out of the Big 3 for free e-mail providers, one of them allows the # character and that one recently allowed server access for free accounts. So I reconfigured my SG accounts to point at my Yahoo Mail account as to where they redirect aliased e-mails, and I can reply to those aliased e-mail back through SG to keep hidden my true e-mail address.

I can now delete my old Comcast e-mail address (kept alive under an old account still inuse by a prior account owner) and start using Yahoo Mail. Only took over 2 years from originally posting the problem to finding a solution but only because Yahoo changed their policy regarding mail server access for free accounts. Would've preferred not mixing in yet another e-mail provider and instead have used Hotmail (Gmail maybe) to get aliased e-mails but this will work, too.