Re:Send your email right to the other person's spam
by yjftsjthsd-h on Sunday February 06, 2022 @01:25AM
(#30230002)
> Any questions were allayed with "oh, you know email. Strange things happens, delays and all that".
The funny thing is, on the real internet with SMTP (so, not in your case but commonly), that's actually true; I once worked at a company that sent a massive amount of email to customers with our own postfix clusters, and it turns out things like "MX was down for a few hours" or "customer's email system rate limited us" - or rarely even "our servers are overloaded and trickling mail out" - are real things and sometimes emails do get held up for hours or days.
Re:Send your email right to the other person's spam
by Scoundreller on Sunday February 06, 2022 @01:30AM
(#30230020)
dunno the back-story, but I've had some "valid for 5 minutes" password reset emails that would arrive expired (after 6 minutes+). And it didn't seem like the kind of company to do shenanigans, just technical voodoo.
Re:Send your email right to the other person's spam
by darnir on Sunday February 06, 2022 @05:02AM
(#30231022)
Public SMTP server issues reminds of the classic 500 Mile Email: https://www.ibiblio.org/harris/500milemail.html
Re:Send your email right to the other person's spam
by rhn_mk1 on Sunday February 06, 2022 @12:37AM
(#30229804)
Nitpickingly, while some SMTP (reicpients list) duplicated that in the email message, SMTP doesn't care about timestamps. It's the MIME stamp that can be messed with.
Most servers add a "Received" line to the MIME contents with some SMTP info, and you can't fool the timestamp inside that.
We weren't even sending email on a public server, we were just using email on the local compsci server. Checking our messages with pine/alpine. The excuses didn't make any sense... but....