On 4/14/22 9:44 PM, Rob McEwen via mailop wrote:
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 *completely* agree.Though falling short of best practice doesn't mean something imperfect is inherently bad.
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.
I don't know how I as a mail operator can cause / persuade / influence a different mail operator to change what they are doing. Certainly not in mass. -- The only real control that I have is over what I do (not) do.
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.
It seems that I misinterpreted your "allowing for an unknown exception" as a larger tolerance for after the fact filtering. -- I'm sorry for that misunderstanding. Thank you for clarifying.
... 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.
Is it fair to summarize your position as the following?Perform any and all filtering /during/ the SMTP transaction that is possible so that the message can be rejected.
What is your opinion on sending DSNs after message acceptance except when the purported sending address is known to be untrustworthy. Thus trying to avoid message black holing.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
