View Single Post
Old 3 Oct 2021, 03:21 PM   #17
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 403
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