3 ms·

This is why I have a catch-all and give each company a different address. I can just forward that address to junk¹ instead of bothering to unsubscribe. It isn't

This is why I have a catch-all and give each company a different address. I can just forward that address to junk¹ instead of bothering to unsubscribe. It isn't just when they ignore their own consent options for sending their own stuff, often mailing lists are hacked out of companies and become junk targets that way. Or they are actively sold: the amount of crap I get to the addresses I have registered with kickstarter²³, paypal, etc., seems to confirm that is very common. [1] Or set it to bounce, but I prefer /dev/null as bouncing increases the chance I'm becoming part of a back-scatter issue. [2] At some point soon I'll get around to cycling those addresses to something else again, I haven't for a while, then the current ones will be redirected to spam training. [3] Including some newsletters specifically targetting people who have interacted with crowd-funding so some project's team has given my address out against my wishes⁴. I wish we could give them specific addresses when supporting, so I could tell who (I don't cycle the main address I use for such things often enough to tell). [4] Though those have saved me money: if I think of supporting a project I search the junk file first and if it has been mentioned by “backer-update”, “grant @ t.k.p.”, “kickstartech”, etc, I'll walk away - but only one has lost my help thus far that way and doubt anyone else is doing it so this petty little victory probably means nothing in the grand scheme of things.

denton-scratch 5y ago
> bouncing increases the chance I'm becoming part of a back-scatter issue Bouncing doesn't cause backscatter, provided it's a real bounce; that means a bounce that is a rejection by your mailserver, performed during the SMTP transaction. The message commonly known as a "bounce message" is technically known as a delivery status notification. The actual bounce message is composed by the sender's mailserver, and can't cause backscatter. Basically, a bounce sent after the SMTP server has said "Message accepted for delivery" is a bogus bounce, and causes backscatter. Sending bogus bounces is a reprehensible practice (and quite useless).
- dspillett 5y ago
  Aye. It sometimes happens because mail gets accepted then put into a local queue for processing (anti-spam checks and other scans) and the fake bounce sent after that. A badly designed system (and such do exist) will do this even for messages they could immediately reject based on the invalid incoming address. It can also happen because there is an intermediate SMTP server between the sender and receiver, the intermediate has dropped the connection to the sender before the final destination rejects, so if you want to bounce at all it has to be a fake bounce. I don't know without checking (and I've been too lazy to test!) if my mail services properly bounce based on target address or fake bounce, so I err on the side of not causing disruption if it is the bad one. I'll be replacing Zimbra with something else (probably self-built from standard parts as my needs are much more limited than when I picked Zimbra many years ago, just mail, nothing else) for my main mail service soon, this will be one of the things to make sure I get right.

denton-scratch 5y ago

> bouncing increases the chance I'm becoming part of a back-scatter issue Bouncing doesn't cause backscatter, provided it's a real bounce; that means a bounce that is a rejection by your mailserver, performed during the SMTP transaction. The message commonly known as a "bounce message" is technically known as a delivery status notification. The actual bounce message is composed by the sender's mailserver, and can't cause backscatter. Basically, a bounce sent after the SMTP server has said "Message accepted for delivery" is a bogus bounce, and causes backscatter. Sending bogus bounces is a reprehensible practice (and quite useless).

dspillett 5y ago
Aye. It sometimes happens because mail gets accepted then put into a local queue for processing (anti-spam checks and other scans) and the fake bounce sent after that. A badly designed system (and such do exist) will do this even for messages they could immediately reject based on the invalid incoming address. It can also happen because there is an intermediate SMTP server between the sender and receiver, the intermediate has dropped the connection to the sender before the final destination rejects, so if you want to bounce at all it has to be a fake bounce. I don't know without checking (and I've been too lazy to test!) if my mail services properly bounce based on target address or fake bounce, so I err on the side of not causing disruption if it is the bad one. I'll be replacing Zimbra with something else (probably self-built from standard parts as my needs are much more limited than when I picked Zimbra many years ago, just mail, nothing else) for my main mail service soon, this will be one of the things to make sure I get right.