Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 25-Feb-2025 08:51:55 JST Rich Felker

   How in 2025 do folks *still* have mail servers that send bounce messages to a forged source address? 🤦

   Offender this time for the hall of shame is kundenserver.de.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 25-Feb-2025 08:52:51 JST Rich Felker

     in reply to

     I wouldn't be surprised if it's even an open relay... 🤦

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 25-Feb-2025 21:24:08 JST Rich Felker

     in reply to

     • LisPi

     @lispi314 Yes and no, but that doesn't give you license to send bounce messages or to be an open relay.

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Tuesday, 25-Feb-2025 21:24:09 JST LisPi

     in reply to
     @dalias Isn't all the origin verification stuff with DNS entries supposed to prevent forgery from being undetected?
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 25-Feb-2025 21:51:52 JST Rich Felker

     in reply to

     • LisPi

     @lispi314 No, that's what I'm saying. You can't do that. You're never allowed to send bounce messages regardless of whether they violate sender policy or not. "Not in violation of policy" doesn't mean "real" except for some draconian corporate senders. But even if it did, sending bounces means your mail system is fubar and probably an open relay.

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Tuesday, 25-Feb-2025 21:51:53 JST LisPi

     in reply to
     @dalias I meant more that it should be trivial to detect when the sender identity is forged and just not send the bounce.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 25-Feb-2025 22:03:21 JST Rich Felker

     in reply to

     • LisPi

     @lispi314 SMTP notifies you at transaction time where it still has a channel to the real responsible party. The illegal behavior these bad sites are doing is accepting the mail for relaying, then generating mail back to the claimed sender if the next relay step is rejected.

     If you're the originating SMTP server you know from authentication who to send errors to if they happen later while trying to deliver. It's only if you're an open relay that you don't.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Tuesday, 25-Feb-2025 22:03:23 JST LisPi

     in reply to
     @dalias You're saying that email shouldn't notify failed delivery at the transport level?
     
     I'd certainly find it pretty helpful to get error emails back when I fail to get any answer from some representative or business for days or weeks. Are they just incompetent or ignoring me, or did they actually never receive it?
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 27-Feb-2025 05:13:23 JST Rich Felker

     in reply to

     • 🆘Bill Cole 🇺🇦
     • LisPi

     @grumpybozo @lispi314 I meant in a protocol sense but in some jurisdictions I guess it might violate anti spam laws too. 🙃

   • Embed this notice
     🆘Bill Cole 🇺🇦 (grumpybozo@toad.social)'s status on Thursday, 27-Feb-2025 05:13:24 JST 🆘Bill Cole 🇺🇦

     in reply to

     • LisPi

     @dalias @lispi314 If you're going to call it "illegal" I’d love to see a relevant citation of law supported by litigation results.

     Or even a single reference to supporting advice in an RFC (which cannot make anything illegal in any sense. )

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 27-Feb-2025 05:39:09 JST Rich Felker

     in reply to

     • 🆘Bill Cole 🇺🇦
     • LisPi

     @grumpybozo @lispi314 You don't accept mail you can't either deliver or conclusively validate the envelope sender for (e.g. by them having authenticated to your outgoing server with credentials).

   • Embed this notice
     🆘Bill Cole 🇺🇦 (grumpybozo@toad.social)'s status on Thursday, 27-Feb-2025 05:39:10 JST 🆘Bill Cole 🇺🇦

     in reply to

     • LisPi

     @dalias @lispi314

     What protocol would that be? What normative document agrees with you that mail should be silently dropped after having been accepted with some basis for trusting the envelope sender? (e.g. SPF affirmative pass, aligned valid DKIM signature, etc.)

     Note that I am not arguing that one should generate bounces lightly. Everything that can be checked at SMTP end-of-data before acceptance should be but there are edge cases where a proper bounce message should be sent.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 27-Feb-2025 08:08:01 JST Rich Felker

     in reply to

     • 🆘Bill Cole 🇺🇦
     • LisPi

     @grumpybozo @lispi314 The "users get deleted" race seems irrelevant. There's no distinction to sender between "mail was silently dropped before delivery because user was deleted" and "mail was delivered but recipient never saw it because account was deleted immediately after delivery".

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     🆘Bill Cole 🇺🇦 (grumpybozo@toad.social)'s status on Thursday, 27-Feb-2025 08:08:03 JST 🆘Bill Cole 🇺🇦

     in reply to

     • LisPi

     @dalias @lispi314
     Unless the 250 reply at SMTP EoD is delayed until real final delivery, it is not possible to be certain of final deliverability. Small systems running Sendmail are able do that but I don't believe that any other widespread MTA even offers synchronous final delivery during SMTP time. It's not feasible at scale.
     If a message gets queued, it can always fail at the next hop. Users get deleted between accept and deliver. Mailboxes fill. LMTP receivers fall over mid-transaction.