On 2022-08-16 12:05:43 -0400, Kris Deugau wrote: > Vincent Lefevre wrote: > > On 2022-08-15 10:39:05 -0400, Kris Deugau wrote: > > > Vincent Lefevre wrote: > > > > Rejecting mail (instead of accepting it and dropping it) is useful > > > > in case of false positives. > > > > > > I'm a bit torn on this. > > > > > > On the one hand, yes, the sender now knows for sure their message didn't > > > get > > > through*. > > > > > > On the other hand, the sender now calls *their* outgoing mail provider to > > > complain "You wouldn't let my message through!", and trying to explain to > > > someone that no, really, we can't do anything about this because it's the > > > recipient's system that doesn't like you is.... sometimes painfully > > > tedious. > > > > Well, the outgoing mail provider (or IP address supplier) is sometimes > > the culprit, e.g. by letting spam out. > > True. But if spam filters everywhere were perfect, spam wouldn't be such a > big problem. > > And, quite reasonably, most rejections for spam include very little or no > detail, so aside from DNSBL-based rejections the sending platform has > essentially zero information beyond "the receiving system doesn't like us". > Which can't be troubleshot from the sending side without at least some kind > of feedback from the receiving side.
Minimal information should at least be included with the 550 status. This is also useful for the receiving side in order to know whether the antispam rules are effective (by checking the logs). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
