4 ms·

At the point it's in the queue, it's already a composed email. Doing a file search and deleting the email file might be possible. I don't know how realistic t

At the point it's in the queue, it's already a composed email. Doing a file search and deleting the email file might be possible. I don't know how realistic that is though. We built your customized email 4 hours ago. It's sitting in a directory somewhere waiting to be read and sent out to gmail. We're waiting because we already sent "X" emails to gmail addresses 3 minutes ago, and we need to wait "Z" more minutes. It might be in the list of emails to be sent as soon as the gates open up again. It might not be ready to go until another 50,000 emails before it have been sent. So, let's say you've decided you don't want to get our emails anymore. Great. We've updated the appropriate tables. Next cron job will skip you. Now let's implement your criteria. We've got to tell the MTA to figure out which is your email, and delete it from the queue. Hopefully we got to the MTA in time. We might not have. Remember the example I initially gave? You might be receiving the mailing 2 seconds after you unsubscribed. So we've spent some measurable time trying to prevent something that's already happened. We don't have enough unsubscribers in general that this is going to cause a significant overhead. The thing is, I'm not even sure I can do that. Our routing application is a 3rd party commercial application that we don't have the source code to. Not to mention, we're going to have to hop back and forth between machines as our databases are elsewhere. Not even sure they're in the same data center, now that I think about it. I really don't want to look up the NAT information to work this out for a simple internet discussion. I'm gonna punt and say, "I dunno. I know how my part of the company works, and I'm still learning it. Maybe there's a better way to do it, and if you have information on commercial products that will do what you're stating is the desired goal, I'll do some research on them, and make recommendations to our company if they look viable." I'm a C# developer. I'm still not quite sure how I ended up handling email. :D

inetknght 7y ago
If you were talking about the difference of a few minutes, then sure I'd let it pass. But hours? No, that's ridiculous. How long does it take to check if the destination email address of an outbound email has been unsubscribed? If it takes long enough to make it so you can't maximize your rate limit then you're doing it wrong.
saghm 7y ago
> At the point it's in the queue, it's already a composed email. So just...don't send it? I don't see why having done prior work to compose it means that you have to send it. You could argue that it's a waste of resources to have composed it and not sent it, but that's a sunk cost you can't get back, so why not just throw it away if you already know that's what I prefer?
- vardump 7y ago
  > So just...don't send it? I don't see why having done prior work to compose it means that you have to send it. So just heavily modify sendmail/qmail/whatever to maintain a list of email addresses for which it shouldn't send it? Not associated with the grandparent, but the software likely composes and immediately "sends" the email, at which point it's going to be in MTA queue that's completely oblivious to the fact some email addresses have been unsubscribed since they entered the queue. Overall, what you're suggesting sounds somewhat unreasonable. Once the email is "sent" (actually, added to MTA queue!), he might have no control whatsoever what the MTA does. If you throw a stone, stopping it mid-air can be... hard. Perhaps it's doable. But is it a reasonable expectation?

inetknght 7y ago

If you were talking about the difference of a few minutes, then sure I'd let it pass. But hours? No, that's ridiculous. How long does it take to check if the destination email address of an outbound email has been unsubscribed? If it takes long enough to make it so you can't maximize your rate limit then you're doing it wrong.

saghm 7y ago

> At the point it's in the queue, it's already a composed email. So just...don't send it? I don't see why having done prior work to compose it means that you have to send it. You could argue that it's a waste of resources to have composed it and not sent it, but that's a sunk cost you can't get back, so why not just throw it away if you already know that's what I prefer?

vardump 7y ago
> So just...don't send it? I don't see why having done prior work to compose it means that you have to send it. So just heavily modify sendmail/qmail/whatever to maintain a list of email addresses for which it shouldn't send it? Not associated with the grandparent, but the software likely composes and immediately "sends" the email, at which point it's going to be in MTA queue that's completely oblivious to the fact some email addresses have been unsubscribed since they entered the queue. Overall, what you're suggesting sounds somewhat unreasonable. Once the email is "sent" (actually, added to MTA queue!), he might have no control whatsoever what the MTA does. If you throw a stone, stopping it mid-air can be... hard. Perhaps it's doable. But is it a reasonable expectation?