Thread: Spam protection
View Single Post
Old 19 Jul 2019, 01:17 PM   #20
xyzzy
Essential Contributor
 
Join Date: May 2018
Posts: 474
Quote:
Originally Posted by Mr David View Post
In superseded iterations of the FM web user interface, it used to be simple enough to change the From address field on the fly when drafting a reply. It is not possible to do this in my account these days.
The "catchall/wildcard" form of send identity (*@aliasname.alias.tld) does let you create anything you want for that alias. The only problem is you always have to edit the part corresponding to the * since the FM UI defaults to whatever the currently selected From name (in the drop down) to replace the *. Very annoying, easy to overlook, and that's just one of a number of annoying things I discovered trying to use catahalls.

Quote:
Options to change the From address for outgoing messages in my account are limited to the alias addresses I have registered, and my main account address used for login. These can be selected from a drop down menu on the Compose screen.
The From drop down list comes from the sending identities settings which includes all your aliases (unless you explicitly delete them in the sending identities) and the external addressess (using new FM UI naming conventions) which are the Mail Fetch accounts. When you create an alias FM adds it to the sending identities for you. So that's telling me you do have the sending identities defined even if you didn't explicitly define them yourself.

What isn't created explicitly are catchalls or specific additional email address using those aliases (for example shop.retailer@aliasname.alias.tld). So if you have an alias aliasname@alias.tld you have to create either a catchall sending identity for it (*@aliasname.alias.tld) and edit the from every time you select it as the sender address (with that FM lets you edit it) or create explicit sending identity like your shop.retailer@aliasname.alias.tld so that it appears in the From list. If you haven't done either of these then I guess you are only using those to receive email and mot send to them. This is what I was trying to clear up when I asked you about this in my previous post.

Quote:
If you know of a link to FM documentation explaining how to create sender identities that can be applied to the From field in outgoing messages I'd like to see it.
What little there is the stuff on catchalls is here and the identities is here although not yet updated to the new UI references. But I suspect you already know about these. I used those as starting points and then just played around to see what I could get away with!

Quote:
On occasion, when such an address has been provided to an online retailer with whom I've needed to engage in customer service correspondence, I haven't bothered trying to set up an identity. I just use the base identity/alias email address in my replies.
Which is what I was concluding above but thanks for confirming it.

Quote:
In many instances the customer support begins with filling out a web form on the site of the entity. The entity's reply is sent to the unique address I gave them; my reply to the first customer service response does not have subdomain details in the From address. I have never had anyone create a fuss over the slightly different address used in my replies; same if I create a customer service query from first principles. If an alias address has been provided, I make sure to use the correct one in messages I send.
Ok, I just I'm a bit anal about these things and would prefer to use only the email address they know me by. BUT...

Quote:
However, if unique aliases are made for every online entity you deal with, you could very quickly wind up managing a list of dozens of aliases. Selecting the right one from a very long list in a drop down menu might be tedious and prone to error.
Hmm, have to think that one over a bit.

Thanks.

Update:
A little out of order but you mentioned an example:
Quote:
ivm@mrdavid.fmdomain.dom
A random name might also be substituted for the subdomain details.
Of course these substituted details were themselves unique, so it was easy to block them with a rule. Spam with continued random substitution of subdomain address details has not so far made it through to my account.
What rule would you use? A check of the string before the @ doesn't contain any dot's for instance?
xyzzy is offline   Reply With Quote