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).josh wrote:I use gmail and reply address masking with the # all the time.
- 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.