On 4/14/2022 8:31 PM, Grant Taylor via mailop wrote:
There are a number of reasons why a message will not make it to the Inbox /and/ the sender not receive a bounce message. -- There are some technical complications, e.g. systems breaking DSNs, and some non-technical / human reasons, e.g. questionable recipient side filters.
Still, that all systems are imperfect - isn't and shouldn't be an excuse to not aim for best practices, and that's even less of a valid excuse to institutionalize or hard-wire mediocrity.
I don't know of any way to effect change / improvement with the parties that want only do things against the spirit of RFCs and / or what (end) users expect to happen.
Not sure I follow you here - but if anything - my recommendations were going a step further than RFCs, but not actually defying or breaking RFCs.
Because I would actually like to discuss it further in the spirit of coming to an understanding of what each other meant, even if we continue to disagree with you.
Here is a key distinction that might help - when I said that I was open to a very limited/rare after-connection time filtering, and then gave the example of a zero-day virus not being delivered to the inbox due to addition information discovered in after-connection filtering - here is a huge distinction - I was implying that the spam filter has an amazing level of accuracy in determining so - and I'm also going by the very sound and reasonable principle that a messages that might potentially be a hand-typed legit email - are much more deserving of getting a connection time response that accurately reflects the status of the message - whereas the criminal sending a zero-day virus deserves NOTHING.
There is some Occam's Razor / Parsimony being applied that if you are okay with something on a very limited basis, you are okay with it some to be determined amount of time. Thus the question becomes one of how much time.
See my earlier statement in this post - there were underlying principles at work that drew somewhat of a very principled line. I think it's clear that my general stance is that routine after-the-connection filtering is NOT ok - but I was trying to rack my brains for some scenarios where it MIGHT be acceptable on a limited basis - because it's a good thing to try to see things from others' perspectives and to try to understand how other methods might be better, at least in some circumstances. So I attempted to do just that in this situation. But even as I was able to think of a circumstance where after-connection spam filtering might be a good practice, I still kept the best interest of legit non-spamming senders/receivers in mind. But you seemed to interprete taking that limited circumstance and thinking of this as just different degrees of the same thing, or some kind of continuum based on someone's subjective opinion - but that actually doesn't apply in this case because I was consistently maintaining the idea that messages that MIGHT be from legit good faith senders still OUGHT to get this connection-time feedback - whereas - in contrast - messages known to contain viruses or malware - with a high degree of certainty - are situations where these are sent by actual criminals - and those senders deserve nothing.
-- Rob McEwen, invaluement
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
