Sep 17 2020
- last edited on
Sep 23 2020
Oct 04 2020 11:24 PM
Lots of cool new features and good work team.
One question that I have and I'm sure Microsoft would had debated this internally. Benefits of having plus addresses, I do get its good for newsletter management. But do we all think the spammers are really going to care. Isn't it obvious to just skip\trim the plus part altogether if identify the actual email address and email that instead if they really want to do is spam you.
Even if you say about bulk processing, how difficult will it be to trim that off programmatically.
There are plus sides to it, and not undermining the overall feature. Maybe SendAs the plus address could next inline.
Oct 05 2020 10:14 AM
I'm not sure I understand why plus addressing is a hot topic AND it makes me curious how the inclusion of a + symbol might trick/trip anti-spam. Also, as another has suggested, couldn't someone (hacker, spammer) simply bulk update their obtained/purchased list to remove everything starting with (including) + and up to @?
Exchange hasn't supported plus addressing ever (it's been around for what seems like ever) and now it does...why now?
What am I missing?
Oh, I'm also curious...can you include more than a single + (or any other subsequent) symbol? For example:
firstname.lastname@example.org or email@example.com or firstname.lastname@example.org
Oct 05 2020 02:45 PM
@Satyajit321 Agreed of course that's possible and not terribly difficult for a spammer to do. We're not suggesting it's a super powerful anti-spam feature by any means. It's just one of the potential benefits of disposable addresses (that plus addressing enables) that's mentioned in Internet discussions and publications, for example here https://en.wikipedia.org/wiki/Disposable_email_address.
Oct 05 2020 06:29 PM - edited Oct 07 2020 10:29 PM
@lance-aughey see my previous post RE plus addresses and spammers.
>>Exchange hasn't supported plus addressing ever (it's been around for what seems like ever) and now it does...why now?
Because over 6,000 O365 customers asked for for us to support it on UserVoice. If you have any particular asks you'd like to see us do, go vote for any existing ones there or post your own. The more votes for it, the more likely we'll do it.
>>Oh, I'm also curious...can you include more than a single + (or any other subsequent) symbol?
<edited on 10/7/2020 to correct previously misleading statements>
If the original alias includes pluses you can still have those and then add an additional + suffix. But only a single + is supported in the plus suffix.
1) Start with email@example.com --> add +++123 as the plus suffix --> firstname.lastname@example.org
Nope, not supported.
YES - supported.
Nope - not supported.
YES - supported.
<end of edits>
Start with email@example.com and add +1*2$3 as plus suffix --> Yes. Everything after the one + is RFC-compliant and would be considered the plus suffix.
Hope this helps. Cheers!
Oct 06 2020 07:11 AM
Dang, that's a lot of "asks". Honoring the request(s) of users is a good thing, right? I'm very familiar with UserVoice and, forgive me, I oftentimes find myself wondering if voicing such requests actually works...that is, until now! LOL
Thanks for the information!
Oct 07 2020 10:20 PM - edited Oct 07 2020 10:30 PM
@lance-aughey my bad! My colleague owns the feature and I asked him for the definitive answer to the above, but he misunderstood thinking we meant the original was "firstname.lastname@example.org" in all cases - in which case you can only add one + in the plus suffix impromptu. But additional pluses ARE supported if they exist in the original alias. They just cannot be included in the plus suffix you add in real-time. So revamping your examples:
If the original alias is email@example.com then adding "+123" suffix to the local part to produce firstname.lastname@example.org will work.
Assume email@example.com then adding "+1*2$3" to produce firstname.lastname@example.org will work.
Sorry for the mix-up! I've edited my previous post to correct the misleading/false statements for posterity. Hopefully I didn't confuse matters. :)