Above thread created 2 days ago but also isn’t this a broader bug? I was getting no emails on gmail either fwiw (wanted a recovery code, never got the email).
Let’s just wait and see for this one. I do not think it’s OpenSMTPD specific. The reply there is not from Meta, its from OpenSMTPD saying the bug is on Metas side. Which i think is true. I think they might have a major issue which has nothing to do with OpenSMTPD, Metas mail servers are just failing all round.
Bender•7mo ago
Indeed it appears to be a long running broader bug [1] of 7 years. Perhaps someone could increase log and header verbosity or enable some form of debugging to see what behavior WhatsApp is invoking. It appears this [2] is how to enable debugging in OpenSMTPD. Once enabled one could trigger an email through WhatsApp to see specifically what it doing. I am nosy and curious enough that I hope someone posts the debug output here after sensitive stuff is redacted. I do not have a WhatsApp account.
There’s no evidence it’s a bug in opensmtpd, rather it’s that other SMTP clients such as WhatsApp’s mail servers are assuming support for the (non-mandatory) PIPELINING extension instead of respecting the EHLO-advertised (lack of) support.
Bender•7mo ago
There’s no evidence
That is exactly why I would enable debugging or tracing and see who is sending what and whom is responding or waiting on something expected with timestamps so that nobody is guessing. The tracing should occur on both the sending and receiving side.
Excellent. That shows debugging will not be enough and one should at least enable tracing [1] probably on both the ZuckMail and OpenSMTPD side. FB's security team should be able to replicate this on the Zuck side if someone has a current contact. I know that a few of them lurk here. I think it's the least they can do after trying to abuse my liver and luring away an amazing coworker with the beautiful blue-haired girl.
Not supporting pipelining is a somewhat effective low effort spam filter. Spammers don't have time to wait for response codes, just blast the message and move on to the next sucker.
eqvinox•7mo ago
exim, if configured to do so (which is a reasonable initial spam barrier), will also reject mails due to this behaviour. It's sufficiently common (for spam) that I filtered it from logs to avoid junk buildup.
AnotherGoodName•7mo ago
Let’s just wait and see for this one. I do not think it’s OpenSMTPD specific. The reply there is not from Meta, its from OpenSMTPD saying the bug is on Metas side. Which i think is true. I think they might have a major issue which has nothing to do with OpenSMTPD, Metas mail servers are just failing all round.
Bender•7mo ago
[1] - https://unix.stackexchange.com/questions/392729/opensmtpd-pi...
[2] - https://wiki.archlinux.org/title/OpenSMTPD#Subsystem_tracing
semiquaver•7mo ago
Bender•7mo ago
That is exactly why I would enable debugging or tracing and see who is sending what and whom is responding or waiting on something expected with timestamps so that nobody is guessing. The tracing should occur on both the sending and receiving side.
JdeBP•7mo ago
* https://github.com/OpenSMTPD/OpenSMTPD/issues/451
Bender•7mo ago
[1] - https://wiki.archlinux.org/title/OpenSMTPD#Subsystem_tracing
JdeBP•7mo ago
* https://marc.info/?l=opensmtpd-misc&m=141543622103232&w=2
Coincidentally, I was just talking about the mess that SMTP got into with all this.
* https://news.ycombinator.com/item?id=44285357