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 3 Oct 2021, 12:23 PM   #16
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,952
Quote:
Originally Posted by JeremyNicoll View Post
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 [email protected] 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 "[email protected]" to form "[email protected]", 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?
As is often the case, assuming you can simplify features like this successfully starts to break down when you consider the situation with care. Suppose company.com decided to host its email at Fastmail. They properly define who is to receive emails to each email address at the company.com domain, and set up specific sending identities when multiple users are allowed to send on behalf of specific email addresses. Do you really want a user with the email address [email protected]com to have the ability to edit the sending address to be [email protected]?

This is one of many issues that is going to arise as soon as you try to simplify what is, when carefully analysed, a complex situation.
BritTim is offline   Reply With Quote
Old 3 Oct 2021, 03:21 PM   #17
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 399
Quote:
Originally Posted by JeremyNicoll View Post
It also occurs to me that if eg xyzzy subsequently deleted their registration of [email protected] 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?
"Any matching wildcard definitions"? Where? You mean the sending identities? If so, no they aren't deleted. Generally sending identities are somewhat separate from other settings you might do and requires you to manually update them. I think creating aliases may be the only instance where sending identities are affected.

At any rate, if the actual alias (e.g., [email protected]) is deleted or disabled then the sending identities would remain but any email sent using these identities will bounce.

Quote:
- 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 "[email protected]" to form "[email protected]", and it would allow me to change my apparent name from "Jeremy Nicoll" to "Some kind of idiot"
I just use a FM alias for this and don't need my own domain (don't have one anyhow). As for what you are saying in your example of "[email protected]" I should point out that is effectively what is happening with an appropriately specified alias target ("deliver to").

Using your example (but I would want, say, grocery as a form of service) I would define alias [email protected] target as "[email protected] Then when the sender sends to [email protected] the X-Resolved-To (where the email is actually delivered) will be [email protected] and fuzzy folder matching will try to deliver the message to folder grocery whose parent is services.

I can create any number of appropriately named services for corresponding named folders all nested (grouped) under the services folder just by making up names for the local part of @services.letterboxes.org. The services folder itself is only used if the nested folder name doesn't exist (as per "fuzzy folder matching rules).

None of this is very complicated so long as you remember "who's on first"! Once set up any names can be chosen to file under the specified target on the fly which no additional work other than creating an appropriately correspondingly named folder, in the example, folders nested under services.

Note that deletion of one of the services is one area which does require a little extra work. Since the actual alias cannot be deleted (which is what started this post), because that would wipe out all the other services, I had to add additional Sieve code to selectively check the destination addresses (e.g., [email protected]) and appropriately reject (or trash) them if I no longer want them. But it's only a simple edit to a list I keep in the Script. Maybe slightly more work than clicking a button in the UI.

Update1:
As for choosing a name that could be defined in the sending identity. But it applies to, in this example, all the services unless edited during compose time. Not sure if that's what you were referring to though.

Update2:
Sorry this post got so long!

Last edited by xyzzy : 3 Oct 2021 at 07:51 PM.
xyzzy is offline   Reply With Quote
Old 3 Oct 2021, 11:12 PM   #18
Mr David
Senior Member
 
Join Date: May 2003
Location: Melbourne, Aus
Posts: 100
Quote:
Originally Posted by xyzzy View Post
Using your example (but I would want, say, grocery as a form of service) I would define alias [email protected] target as "[email protected] Then when the sender sends to [email protected] the X-Resolved-To (where the email is actually delivered) will be [email protected] and fuzzy folder matching will try to deliver the message to folder grocery whose parent is services.
This manipulation of FM's support of aliases is very cool.

When you mentioned it in a recent thread (last week?) I had thought to ask you to expand on the concept. With this explanation I was able to get it to work. (Well, eventually; it took a few tries. It helps to save changes to alias parameters.) Thank you for sharing it.

Testing demonstrated the method can be used to have messages sent to a given alias sorted to any folder in your account. Folder name doesn't have to match alias name.

Just alter the alias's "Deliver to (send to these addresses)" field (alias target) from:
[email protected]
to:
[email protected]
...where testfolder was a parent folder created for my test.
It worked for child folders of testfolder too when I tried [email protected].

It's an elegant means of achieving the effect of subdomain addressing.

Nifty and versatile!

Last edited by Mr David : 5 Oct 2021 at 12:46 PM.
Mr David is offline   Reply With Quote
Old 4 Oct 2021, 02:52 AM   #19
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 334
Quote:
Originally Posted by xyzzy View Post
"Any matching wildcard definitions"? Where? You mean the sending identities? If so, no they aren't deleted.
I'll try again... Right now you have registered [email protected] as one of your addresses, and have a wildcard definition *@service.letterboxes.org that lets you do what you later describe.

If you decide to delete/unregister [email protected] then there's no legitimate use for you of the *@service.letterboxes.org identity for /sending/ emails. That's why I think FM would need to look for such definitions and delete them too.

The rest of what you describe seems to be about what happens when someone else sends email to one of these addresses, which is not what I was talking about.

Quote:
Originally Posted by xyzzy View Post
At any rate, if the actual alias (e.g., [email protected] is deleted or disabled then the sending identities would remain but any email sent using these identities will bounce.
I'm confused. How can you then legitimately send an email that's using as a sender address one of these addresses? I agree that if anyone (else) sends email to one of those addresses it might bounce - but it wouldn't if in the meantime some other user had registered [email protected] as one of their addresses.


Quote:
Originally Posted by xyzzy View Post
As for choosing a name that could be defined in the sending identity. But it applies to, in this example, all the services unless edited during compose time. Not sure if that's what you were referring to though.
As I said in one of the other posts, the only reason I ever used my wildcard Identity was for one-off changes to the /name/ on an Identity. All my identities have sensible names defined on them. Once in a blue moon I might want to send a mail with a facetious phrase in the sender's "name". The wildcard thing let me do that on the Compose screen for a one-off mail. Now I have to edit the Identity, save it, use it, edit it again back to the sensible value and save that ... which is a whole lot more palaver.
JeremyNicoll is offline   Reply With Quote
Old 4 Oct 2021, 02:56 AM   #20
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 334
Quote:
Originally Posted by BritTim View Post
As is often the case, assuming you can simplify features like this successfully starts to break down when you consider the situation with care. Suppose company.com decided to host its email at Fastmail. They properly define who is to receive emails to each email address at the company.com domain, and set up specific sending identities when multiple users are allowed to send on behalf of specific email addresses. Do you really want a user with the email address [email protected] to have the ability to edit the sending address to be [email protected]?

This is one of many issues that is going to arise as soon as you try to simplify what is, when carefully analysed, a complex situation.
OK, I agree. But I described editing available to a /personal/ domain, ie one owned and used by a single person. I have no experience of how FM's system works with multiple users (in either corporate or family-account situations) and I'm sure that produces - as you say - its own complications.
JeremyNicoll is offline   Reply With Quote
Old 4 Oct 2021, 06:45 AM   #21
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 399
Quote:
Originally Posted by JeremyNicoll View Post
I'll try again... Right now you have registered [email protected] as one of your addresses, and have a wildcard definition *@service.letterboxes.org that lets you do what you later describe.

If you decide to delete/unregister [email protected] then there's no legitimate use for you of the *@service.letterboxes.org identity for /sending/ emails. That's why I think FM would need to look for such definitions and delete them too.
Yes there is no legitimate use which is why sending from or to such identities will bounce. FM does not delete the corresponding sending identities if you delete the alias. Maybe they should if the alias is deleted. Not sure about it off you only disable though.

Quote:
The rest of what you describe seems to be about what happens when someone else sends email to one of these addresses, which is not what I was talking about.
I thought I was only responding to the example you posted. Rereading your post I guess the actual subject there was the name specification.

Quote:
I'm confused. How can you then legitimately send an email that's using as a sender address one of these addresses? I agree that if anyone (else) sends email to one of those addresses it might bounce - but it wouldn't if in the meantime some other user had registered [email protected] as one of their addresses.
Yes send/receive will bounce (except possibly during the up to that 15 minute waiting time for the change to take effect).

Quote:
As I said in one of the other posts, the only reason I ever used my wildcard Identity was for one-off changes to the /name/ on an Identity. All my identities have sensible names defined on them. Once in a blue moon I might want to send a mail with a facetious phrase in the sender's "name". The wildcard thing let me do that on the Compose screen for a one-off mail. Now I have to edit the Identity, save it, use it, edit it again back to the sensible value and save that ... which is a whole lot more palaver.
I am not sure I understand. The From field in the compose window for a wildcard sending identity always lets you edit the name. The name specified in the sending identity (if any) is just the default it shows in that identity's compose From field.

Last edited by xyzzy : 4 Oct 2021 at 07:28 AM.
xyzzy is offline   Reply With Quote
Old 5 Oct 2021, 01:26 AM   #22
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 334
Quote:
Originally Posted by xyzzy View Post
I am not sure I understand. The From field in the compose window for a wildcard sending identity always lets you edit the name. The name specified in the sending identity (if any) is just the default it shows in that identity's compose From field.
It might be because your example (which is presumably based on how you used wildcard identities) was for *@service.letterboxes.org so presumably whenever you used that wildcard it was letting you edit details for "service".

But my wildcard was more general, applying to any of my specific letterboxes.org addresses (which had lots of values equivalent to your "service" value). That meant I didn't directly use an identity which specified the "service" part ot the chosen identity. That's why I selected Identities twice on the Compose window's dropdown. I said before that I:

- used the Identities dropdown menu first to pick the asterisk identity

- used 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

My understanding was that I needed to have selected the wildcard to turn on the editable fields, but I needed the second selection to get the required predefined identity loaded into the editable fields.

As far as I understand this, you only make/made one selection from the dropdown. To do the same as you I think I'd need to define multiple wildcard identities rather than the single one I had before. I'm not sure it's worth my while doubling the number of defined identities, just for very rare use of the feature. It's simpler just to do the edits the long-winded way.
JeremyNicoll is offline   Reply With Quote
Old 5 Oct 2021, 06:45 AM   #23
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 399
Quote:
Originally Posted by JeremyNicoll View Post
It might be because your example (which is presumably based on how you used wildcard identities) was for *@service.letterboxes.org so presumably whenever you used that wildcard it was letting you edit details for "service".
Correct, I have 3 different identities for each of my major "service" categories ("disposables", permanent "registrations", and "other" stuff). All the various "services" folders are sorted under them. And that adds those 3 wildcard identities to the compose dropdown menu where, as you say, I have have to edit in the "service" name at compose time. For replies of course the name is already supplied.

Quote:
But my wildcard was more general, applying to any of my specific letterboxes.org addresses (which had lots of values equivalent to your "service" value). That meant I didn't directly use an identity which specified the "service" part ot the chosen identity. That's why I selected Identities twice on the Compose window's dropdown.
- - -
My understanding was that I needed to have selected the wildcard to turn on the editable fields, but I needed the second selection to get the required predefined identity loaded into the editable fields.
Hmm, I'm curious. So what did the sending identity for this scheme look like? I am not familiar that there ever was a way to do this.

Quote:
As far as I understand this, you only make/made one selection from the dropdown. To do the same as you I think I'd need to define multiple wildcard identities rather than the single one I had before. I'm not sure it's worth my while doubling the number of defined identities, just for very rare use of the feature. It's simpler just to do the edits the long-winded way.
See above.
xyzzy is offline   Reply With Quote
Old 5 Oct 2021, 08:48 AM   #24
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 334
Quote:
Originally Posted by xyzzy View Post
Hmm, I'm curious. So what did the sending identity for this scheme look like? I am not familiar that there ever was a way to do this.
name: "Jeremy Nicoll - asterisk fastmail"
value: "*.letterboxes.org"

and all my other identities were normal - ie a name and a valid email address.
JeremyNicoll is offline   Reply With Quote
Old 5 Oct 2021, 11:32 AM   #25
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 399
[quote=JeremyNicoll;622699]name: "Jeremy Nicoll - asterisk fastmail"
value: "*.letterboxes.org"

"*.letterboxes.org" ? What does that mean? Or should that have been "*@letterboxes.org"? If so you could use that to "manufacture" a valid email addresses with the letterboxes.org domain.

Last edited by xyzzy : 5 Oct 2021 at 05:05 PM.
xyzzy is offline   Reply With Quote
Old 5 Oct 2021, 08:45 PM   #26
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 334
Quote:
Originally Posted by xyzzy View Post
"*.letterboxes.org" ? What does that mean?
Well, according to my notes, it meant that exact literal value. I wish I'd kept a screenshot of it before I deleted it a few days ago, because - of course - I can't be certain.

Quote:
Originally Posted by xyzzy View Post
Or should that have been "*@letterboxes.org"?
Maybe, but it's not what my notes said. I'm usually careful when I write notes but perhaps I was wrong this time. I can't tell.

Quote:
Originally Posted by xyzzy View Post
If so you could use that to "manufacture" a valid email addresses with the letterboxes.org domain.
Yes, I understand that in theory it could have let someone do that. I never did that, and it was the open-endedness of this identity that made me raise the issue I thought there was if some automated FM code attempted to verify it.

Just now I tried to recreate the identity in the form I thought it had had, and couldn't. But I also then tried to recreate it in the form you suggest - and was allowed to - but its behaviour does not look the same to me as my old one did a few days ago, so I'm not sure it's conclusive.

However, this latest one, in the same way as my old one last experimented with a few days ago, no longer supports the load it, then load a predefined non-wildcard identity, then edit the latter one facility that I wanted to have it for.
JeremyNicoll is offline   Reply With Quote
Old 6 Oct 2021, 12:04 PM   #27
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 399
Quote:
Originally Posted by JeremyNicoll View Post
However, this latest one, in the same way as my old one last experimented with a few days ago, no longer supports the load it, then load a predefined non-wildcard identity, then edit the latter one facility that I wanted to have it for.
I don't recall the kind of restriction they had on sending identities before they added the new verification "obsession" but I just did a few experiments trying to create some wildcard sending identities and only found *@service.letterboxes.org was allowed. Anything else required some kind of server access settings or was a syntax error.

The sending alias *@letterboxes.org is not allowed without server settings also. But I already have one like this (with a verify button that cannot be used - who could I verify with) and it still works. I think this because mine existed before this new verify stuff was added so it's sneaking in through the "back door".

I don't know what limitations were on creating sending identities before this new verify stuff was added. So whatever you had prior to it they are a lot more restrictive (obsessive?) with making sure you can only use verified stuff now. Wildcard identities involving an alias can only be used when it uses the entire alias (e.g., [email protected]) so those don't need verification.

I was only "probing" you for how you were doing what you said just for my own education of another possible piece of functionality that could maybe be useful to me in the future. What's good about this forum is it can be a great source of tricks others are using.

Last edited by xyzzy : 6 Oct 2021 at 12:54 PM.
xyzzy is offline   Reply With Quote
Old 7 Oct 2021, 12:08 AM   #28
JeremyNicoll
Essential Contributor
 
Join Date: Dec 2017
Location: Scotland
Posts: 334
Quote:
Originally Posted by xyzzy View Post
The sending alias *@letterboxes.org is not allowed without server settings also.
Actually it is, but you have to open the Advanced part of the definitions and turn off FM's assumption that the identity will use an external SMTP server, whereupon the fields for server settings vanish.


Quote:
Originally Posted by xyzzy View Post
I was only "probing" you for how you were doing what you said just for my own education of another possible piece of functionality that could maybe be useful to me in the future. What's good about this forum is it can be a great source of tricks others are using.
Absolutely. It was n5bb's post - no 8 in the discussion at http://www.emaildiscussions.com/showthread.php?t=73905
that made me try this in the first place. (I kept the URL and the contents of the post in my notes along with (sorry) what now looks like a typo in my notes about what I set up).
JeremyNicoll is offline   Reply With Quote
Old 7 Oct 2021, 06:09 AM   #29
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 399
Quote:
Originally Posted by JeremyNicoll View Post
Actually it is, but you have to open the Advanced part of the definitions and turn off FM's assumption that the identity will use an external SMTP server, whereupon the fields for server settings vanish.
Just tried it. Yes, they do disappear but unfortunately the verification requirement doesn't. The identity list tags the identity as "unverified" along with the verify button. Trying to compose with it also displays a request for verification.

This is different from my pre-existing one which also has a verify button but is not tagged as "unverified" which is probably why it lets me send with it. I don't really have any use for it but I'll keep it in just to see if they ever catch it!
xyzzy is offline   Reply With Quote
Old 10 Oct 2021, 07:08 AM   #30
hadaso
The "e" in e-mail
 
Join Date: Oct 2002
Location: Holon, Israel.
Posts: 4,601
Quote:
Originally Posted by BritTim View Post
...
Do you really want a user with the email address [email protected] to have the ability to edit the sending address to be [email protected]?
...
Many years ago one of FastMail's C*Os (there were two people at FastMail back then: Jeremey Howard and Rob Mueller, so it must have been one of them) explained here in the forum why there's no need for FastMail to prevent this scenario, that is to restrict what's on the From header (and envelope header. The reason given was that anyone can send as janitor#company.com from practically anywhere, usiong an email client or telnet to port 26 at company.com's MX server). This was opposed to Gmail's requirement to verify every single address used in the From field.
I had three identities that required verification.
One of them was my work email address (at my employer's domain) that I easily verified (but that would not prevent mail sent from it bouncing, since delivering to addresses within the organization fro a source outside would require a different envelope-from, but this feature was cancel long ago).

Another is is *@xoxy.net (which is any address at one of SpamGourmet's domains) that I cannot verify because I don't receive all the email for that domain, only email sent to *[email protected] or *.*[email protected] (user is one of my two SpamGourmet accounts). I use the identity *@xoxy.net because FastMail identities do not allow the scheme *[email protected] Right now it still works (I tried it now and it allowed me to send email, and the email was sent and received). The only annoyance is having to retype my username part of the address each time. When verification of identities is enforced It would end one use scenario that I used with FastMail for many years now.
The third identity I have that for some unknown reason requires verification is in my own domain, hosted by Fastmail (both DNS and MX), is not a wildcard identity, just a simple email address, and that address is defined as an alias in my account. the alias is [email protected] and it targets [email protected] (it was a scheme that effectively bounced all mail to that address, and to *@bounce.mydomain.tld) before the checkbox to disable delivery to an alias was introduced. As it is a legitimate alias in FastMail, not even set to reject email, I wonder why verification is required for it.
hadaso 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 02:48 PM.

 

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