3 ms·

> Also some junk senders seem to have worked out that the sub-domain I use for the per-entity addresses is a catch-all, I need to address that at some point. C

> Also some junk senders seem to have worked out that the sub-domain I use for the per-entity addresses is a catch-all, I need to address that at some point. Could you elaborate how you'd address that?

dspillett 2y ago
There are a few options I've thought of, including these ones off the top of my head: 1. Just enable each on first use, instead of using a catch-all at all, though there is a danger there of bounces due to mistakes on my part. 2. Keep the catch-all but send to a junk folder unless the destination address is on a white-list, this has the advantage that if I forget to add the new address (or do it incorrectly) no mail is lost as I can move it out of junk after the fact (as long as I notice within 30 days). 3. Generate the addresses either fully or as <picked-portion>.<truncated-salted-hash-of-that>@sub.domain.tld, so ea588e3be96e89.8177be49@sub.here.com or SomeShop.499ec679@sub.there.com, and use programmatic filtering to decide where the messages go (junk unless the hash matches). The disadvantages of that are needing to have access to the generator at any time I need an address, difficulty giving addresses verbally (there would be transcription errors), and it does nothing for existing addresses. Option 2 is probably the winner there. Every now and then I think of another option then dismiss it as overcomplicated or otherwise not workable.
- nucleardog 2y ago
  I think the idea of having a token in the address could work! Unless you’re being specifically targeted, it doesn’t need to be anything particularly long or secure though—just needs to not fit the same pattern as everyone else. It could be as simple as “the letter before the first letter and the letter after the last letter” or something easy enough to generate in your head when filling out a paper form. (E.g., “hackernews@“ becomes “hackernews.gt@“; “google@“ becomes “google.ff@“) Or “numbers of vowels mod 10” (“facebook@“ becomes “facebook.4@“; “medium@“ becomes “medium.3@“). You could always combine this with option 2 as well. Anything that has a valid token goes through the regular filters, everything without goes straight to junk. … In fact, I think I’m going to do this for my own domain.
  - dspillett 2y ago
    You're right, that is a good simplification of that option to make it less tech dependent: * Generate addresses with that process (that can be done in the head) * Programmatically verify the incoming addresses to filter junk/not (hopefully not difficult with postfix, just use the “standard” config-in-db setup with a stored procedure to do the mapping instead of a simple SELECT so you can check the checksum (in fact, it should be possible with a SELECT but I expect the syntax will be more messy that way)) * Still have a whitelist for addresses previously used, unless using a new sub-domain for this setup * Still send mismatches to a junk folder not /dev/null in case of mistakes I might go that way when I finally get around to rebuilding & migrating my mail server(s)…

dspillett 2y ago

There are a few options I've thought of, including these ones off the top of my head: 1. Just enable each on first use, instead of using a catch-all at all, though there is a danger there of bounces due to mistakes on my part. 2. Keep the catch-all but send to a junk folder unless the destination address is on a white-list, this has the advantage that if I forget to add the new address (or do it incorrectly) no mail is lost as I can move it out of junk after the fact (as long as I notice within 30 days). 3. Generate the addresses either fully or as <picked-portion>.<truncated-salted-hash-of-that>@sub.domain.tld, so ea588e3be96e89.8177be49@sub.here.com or SomeShop.499ec679@sub.there.com, and use programmatic filtering to decide where the messages go (junk unless the hash matches). The disadvantages of that are needing to have access to the generator at any time I need an address, difficulty giving addresses verbally (there would be transcription errors), and it does nothing for existing addresses. Option 2 is probably the winner there. Every now and then I think of another option then dismiss it as overcomplicated or otherwise not workable.

nucleardog 2y ago
I think the idea of having a token in the address could work! Unless you’re being specifically targeted, it doesn’t need to be anything particularly long or secure though—just needs to not fit the same pattern as everyone else. It could be as simple as “the letter before the first letter and the letter after the last letter” or something easy enough to generate in your head when filling out a paper form. (E.g., “hackernews@“ becomes “hackernews.gt@“; “google@“ becomes “google.ff@“) Or “numbers of vowels mod 10” (“facebook@“ becomes “facebook.4@“; “medium@“ becomes “medium.3@“). You could always combine this with option 2 as well. Anything that has a valid token goes through the regular filters, everything without goes straight to junk. … In fact, I think I’m going to do this for my own domain.
- dspillett 2y ago
  You're right, that is a good simplification of that option to make it less tech dependent: * Generate addresses with that process (that can be done in the head) * Programmatically verify the incoming addresses to filter junk/not (hopefully not difficult with postfix, just use the “standard” config-in-db setup with a stored procedure to do the mapping instead of a simple SELECT so you can check the checksum (in fact, it should be possible with a SELECT but I expect the syntax will be more messy that way)) * Still have a whitelist for addresses previously used, unless using a new sub-domain for this setup * Still send mismatches to a junk folder not /dev/null in case of mistakes I might go that way when I finally get around to rebuilding & migrating my mail server(s)…