EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 29 Sep 2021, 07:08 AM   #1
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 474
"Verify" sending identities

I just noticed that two of my sending identities had a "Verify" button showing on them. So check your sending identities to see if you have that button on any of them.

Last edited by xyzzy : 29 Sep 2021 at 11:58 AM.
xyzzy is offline   Reply With Quote

Old 30 Sep 2021, 04:22 AM   #2
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
Interesting. I don't host a domain with FM so most of my usable identities are defined with one or other of the many domains that FM own.

A few are defined in terms of a domain I own that's hosted elsewhere, and all of those had acquired a "Verify" button. On clicking it the FM website offered to send a code to the address involved, which I found on the other system, entered on FM's system, and the requirement to verify them was satisfied.

One of my identities though is defined as an "asterisk" one and for that I was given an opportunity to send the confirmation code to something nonsensical. I did not let it try it. Meantime I've raised a ticket with FM to ask if they've considered that sort of identity carefully enough in their Verify logic.
JeremyNicoll is offline   Reply With Quote
Old 30 Sep 2021, 05:05 AM   #3
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 474
Quote:
Originally Posted by JeremyNicoll View Post
One of my identities though is defined as an "asterisk" one and for that I was given an opportunity to send the confirmation code to something nonsensical. I did not let it try it. Meantime I've raised a ticket with FM to ask if they've considered that sort of identity carefully enough in their Verify logic.
I have one of those too. It's for a alias identity of the form, for example *@mm.st. It's only an alias but it still asking to verify even though it is, as you say, "nonsensical" (at least for an alias).

I also had sent a ticket on this and recommended they should not place that verify button on it but display an error or warning instead if, for no other reason, to avoid user confusion since wildcard aliases with subdomains (e.g., *@foo.mm.st) don't require verification (because foo@mm.st was previously created as an alias). I think from a UI point of view some sort of explicit feedback would be desirable instead of placing that button on it.

At the moment they recommended just deleting it. Not sure why I added it in the first place except that it's probably been lying around from the time when I was first learning about sending identities some years ago when using such an identity was convenient to play around with.

I'm keeping it in for a while because I discovered that the verify button on it does not appear in the FM (iPhone) app. I'm curious to see when (or if) it does.

Update:
Just tried a test on that wildcard alias sending identity and it still works even though the verify button is still there.

Last edited by xyzzy : 30 Sep 2021 at 06:06 AM.
xyzzy is offline   Reply With Quote
Old 1 Oct 2021, 02:35 PM   #4
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
We're in the process of verifying all the identities that people use, so that we can turn on stricter controls over sending (not allow email through our servers if the connection is authenticated as user A but the email claims to be from user B).

Eventually if you have a wildcard sending identity at one of our domains, your send will be rejected unless you use one of the specific aliases that you actually own within that domain - you won't be able to send as an arbitrary address in that domain which you haven't claimed.
brong is offline   Reply With Quote
Old 1 Oct 2021, 04:09 PM   #5
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,084
Quote:
Originally Posted by brong View Post
We're in the process of verifying all the identities that people use, so that we can turn on stricter controls over sending (not allow email through our servers if the connection is authenticated as user A but the email claims to be from user B).

Eventually if you have a wildcard sending identity at one of our domains, your send will be rejected unless you use one of the specific aliases that you actually own within that domain - you won't be able to send as an arbitrary address in that domain which you haven't claimed.
Thank you for chiming in. This all seems reasonable, but there is an edge case that could be an issue.

Consider an alias for a colleague's account, where you are also allowed to send on behalf of that alias You both choose to have a wildcard sending identity of *@user1alias.fastmail.com. Now, this will not be an issue for user1, but I assume your plan is to forbid this for user2.
BritTim is offline   Reply With Quote
Old 1 Oct 2021, 04:17 PM   #6
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Quote:
Originally Posted by BritTim View Post
Thank you for chiming in. This all seems reasonable, but there is an edge case that could be an issue.

Consider an alias for a colleague's account, where you are also allowed to send on behalf of that alias You both choose to have a wildcard sending identity of *@user1alias.fastmail.com. Now, this will not be an issue for user1, but I assume your plan is to forbid this for user2.
If it's within the same customer, then the alias is owned by the customer so it's fine. Otherwise... you'll have to create a specific sending identity and verify it. It's enough of an edge case that I'd be tempted to say "change how you're doing things. Maybe by setting up an "SMTP ONLY" app password and having user2 send authenticated back to fastmail as user1 when using that identity.
brong is offline   Reply With Quote
Old 1 Oct 2021, 08:29 PM   #7
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,084
Quote:
Originally Posted by brong View Post
If it's within the same customer, then the alias is owned by the customer so it's fine. Otherwise... you'll have to create a specific sending identity and verify it. It's enough of an edge case that I'd be tempted to say "change how you're doing things. Maybe by setting up an "SMTP ONLY" app password and having user2 send authenticated back to fastmail as user1 when using that identity.
The main use case is where you cover for someone else, and want to be able to reply to emails copied to you, having the reply go back to the original sender. In this kind of situation, the wildcard identity is actually more important for the user who is not the owner of the alias. While slightly inconvenient, the alias owner could set up specific sending aliases as necessary, but this is not going to be a reasonable workflow for occasional cover for a colleague. Yes, if they are combined under the same customer umbrella account, it will probably work out, but there are legitimate cases where this is not the reality.
BritTim is offline   Reply With Quote
Old 1 Oct 2021, 08:32 PM   #8
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Turns out I was wrong, we did figure this one out. If you verify a wildcard alias we send to a random address in that wildcard and consider it verified if you get the code. So this workflow does work.
brong is offline   Reply With Quote
Old 1 Oct 2021, 10:24 PM   #9
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
Quote:
Originally Posted by brong View Post
Turns out I was wrong, we did figure this one out. If you verify a wildcard alias we send to a random address in that wildcard and consider it verified if you get the code. So this workflow does work.
In the example I raised as a ticket [PTN 1471033], my wildcard alias was for

*@letterboxes.org

[For anyone else reading this, that's one of the FM-owned domains that anyone can use.]

I have a handful of registered specific letterboxes.org addresses. If you randomly pick an address @letterboxes.org you're extremely likely to spam someone who isn't me.

My suggestion that you don't offer a Verify button for such Identities has been given the "this is not on our roadmap" response, which I think is poor.
JeremyNicoll is offline   Reply With Quote
Old 2 Oct 2021, 02:41 AM   #10
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,084
Quote:
Originally Posted by JeremyNicoll View Post
In the example I raised as a ticket [PTN 1471033], my wildcard alias was for

*@letterboxes.org

[For anyone else reading this, that's one of the FM-owned domains that anyone can use.]

I have a handful of registered specific letterboxes.org addresses. If you randomly pick an address @letterboxes.org you're extremely likely to spam someone who isn't me.

My suggestion that you don't offer a Verify button for such Identities has been given the "this is not on our roadmap" response, which I think is poor.
In the example you have given, I think the planned changes are reasonable. A wildcard alias that allows you to send messages identifying you as someone you are not while using a Fastmail domain is just the kind of issue the verification process is intended to prevent. If you have set up actual aliases, surely there are already specific sending identities associated with those aliases. Yes, I can see why the example I raised of covering for a colleague could make possession of the wildcard alias convenient, but (unlike in my case of the wildcard for a subdomain) there seems no solution that does not break the whole point of verification.
BritTim is offline   Reply With Quote
Old 2 Oct 2021, 05:05 AM   #11
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 474
Quote:
Originally Posted by BritTim View Post
...but (unlike in my case of the wildcard for a subdomain) there seems no solution that does not break the whole point of verification.
Speaking of breaking am I misinterpreting what is planed, i.e., even wildcard aliases are going to require verification? If so that will mean all the email addresses I've set up for various recipients (e.g., *@service.letterboxes.org) will become useless!. I depend on these with appropriately chosen alias targets (the alias's "Deliver to" setting) to automatically sort into mailboxes for the names I choose for the wildcard.

I think it was also mentioned verify won't be required for aliases I own. So if I own (using the previous example) service@letterboxes.org does that mean FM won't require verification for *@service.letterboxes.org? Currently the verify button is not on them so I assume that's as intended - at the moment. If this changes my entire setup using aliases becomes effectively useless if I have to verify them before I use them.

Just trying to understand all this. If the above is correct then I can see why *@letterboxes.org is an "edge" case so that's why the verify button is there. But as I said in a previous post I could still use it even though it was unverified but note the test I did was to my one of my own aliases.

Last edited by xyzzy : 2 Oct 2021 at 05:17 AM.
xyzzy is offline   Reply With Quote
Old 2 Oct 2021, 10:47 AM   #12
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,084
Quote:
Originally Posted by xyzzy View Post
Speaking of breaking am I misinterpreting what is planed, i.e., even wildcard aliases are going to require verification? If so that will mean all the email addresses I've set up for various recipients (e.g., *@service.letterboxes.org) will become useless!. I depend on these with appropriately chosen alias targets (the alias's "Deliver to" setting) to automatically sort into mailboxes for the names I choose for the wildcard.

I think it was also mentioned verify won't be required for aliases I own. So if I own (using the previous example) service@letterboxes.org does that mean FM won't require verification for *@service.letterboxes.org? Currently the verify button is not on them so I assume that's as intended - at the moment. If this changes my entire setup using aliases becomes effectively useless if I have to verify them before I use them.

Just trying to understand all this. If the above is correct then I can see why *@letterboxes.org is an "edge" case so that's why the verify button is there. But as I said in a previous post I could still use it even though it was unverified but note the test I did was to my one of my own aliases.
There is no problem with your use case. What is intended to be blocked is a wildcard of *@letterboxes.org, which would allow you to spoof someone else's email address when sending an email.
BritTim is offline   Reply With Quote
Old 2 Oct 2021, 11:22 AM   #13
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 474
Quote:
Originally Posted by BritTim View Post
There is no problem with your use case. What is intended to be blocked is a wildcard of *@letterboxes.org, which would allow you to spoof someone else's email address when sending an email.
Thanks for reassuring me. And yes, I see how *@letterboxes.org can be used for spoofing albeit I referred to it as "edge" case simply because, at the moment, I still can still send using that identity even though the verify button is displayed in the (webmail, not the phone app).
xyzzy is offline   Reply With Quote
Old 2 Oct 2021, 09:27 PM   #14
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
Quote:
Originally Posted by BritTim View Post
In the example you have given, I think the planned changes are reasonable. A wildcard alias that allows you to send messages identifying you as someone you are not while using a Fastmail domain is just the kind of issue the verification process is intended to prevent.
Yes of course. I think verification is a good thing.

That's not the point I raised in my ticket with FM. The point is that, having an alias of the form "*@letterboxes.org", the Verify logic is nonsensical or possibly a source of spam from FM.

Nonsensical - because there's no way that FM could verify it so they shouldn't be trying to. (They should probably also disallow wildcard identities for target domains that are not entirely owned by the user.)

Spam - because if (as they say) they'd send a confirmation mail to a random address in the specified domain, they'd send it to someone that isn't me. That someone would be being spammed by FM.


Also, the reason I had that Identity was because it allowed me to edit the /name/ part of a FROM address as I was composing a mail. I am not an idiot and did not use it alter the local part of a letterboxes.org address.

What I'd do when composing was:
- use the Identities dropdown menu first to pick the asterisk identity
- use the Identities dropdown menu again to pick the letterboxes identity that I actually wanted to use
- the system then showed me the chosen Identity in editable fields, whereupon I although in theory I could change any part of it, I only ever changed the name, eg changing "Jeremy Nicoll" to something facetious.

This sneaky way of editing a FROM address no longer works, and so I have deleted the asterisk alias. Now if I want to send an email with a silly name in the from field, I have to go through the much more long-winded method of going into Settings, editing the chosen Identity, saving it, composing the mail using it, then returning to Settings and reinstating the old value in the identity.
JeremyNicoll is offline   Reply With Quote
Old 2 Oct 2021, 10:18 PM   #15
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 483
Quote:
Originally Posted by JeremyNicoll View Post
Nonsensical - because there's no way that FM could verify it so they shouldn't be trying to. (They should probably also disallow wildcard identities for target domains that are not entirely owned by the user.)
I wrote the "They should probably also disallow..." part before I read how xyzzy uses eg *@service.letterboxes.org so clearly they'd need to allow that sort of thing.

It also occurs to me that if eg xyzzy subsequently deleted their registration of service@letterboxes.org FM's code would have to go looking for any matching wildcard definitions and delete them too. I wonder if FM's code does that now?


It seems to me that the whole wildcard thing is more complicated than it needs to be. Wouldn't it just be simpler if -

- for personal domains, hosted by FM so they know who owns it, the Compose screen allowed the owner to edit anything to the left of the "@" in a sender's address

- for personal domains, hosted elsewhere, but entirely owned by the customer [who'd have to prove that somehow], the same

- for FM-owned domains, the Compose screen allowed a user to edit anything to the left of the entire registered email address. That'd allow xyzzy to enter eg "grocery" and an implied dot to the left of "services@letterboxes.org" to form "grocery.services@letterboxes.org", and it would allow me to change my apparent name from "Jeremy Nicoll" to "Some kind of idiot"

- for individual addresses at domains hosted elsewhere, each address verified as is being done now, the Compose screen allowed a user to edit anything to the left of the entire verified email address.


You wouldn't need wildcard definitions at all, just more sophisticated logic in the Compose screen.


And another thing... Just because I can verify today that I have access to emails sent to a particular address doesn't mean that that will be true for evermore. How often will FM re-verify these addresses?
JeremyNicoll is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 04:57 PM.

 

Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy