On Sat, 09 Feb 2019 23:38:15 +0100, Ð?илÑ?н Ð?алаÑ?зов said:
if on 250-GREYLIST on retries the IP address of the client is changed, then
the Greylist-421-retry=00:00:10 puzzle is not solved and the time begins again
from the beginning on each IP-client-address change. This is not in the
interest of the sender.
As I mentioned, I don't think it rises to the level of a SHALL - that's usually
reserved for things where failure to do so causes a high risk of the protocol
failing to work properly. Retrying the transaction from a different IP address
merely means that the greylist timer will be reset - that's well into SHOULD
territory.
When I wrote that as user I do not want to have a Spam mailbox, I meant that
I do not want to have a place, where the provider mixes real spam with false
positives. I am willing to have means to train the spam filter and undo the
training.
So instead you mix delayed-delivery reports with spam in the sender's mailbox.
I'm not sure that's much of a win.
Also, how does the provider distinguish between real spam and false positives,
so that the user doesn't have to? (Hint - it's easy to get it right 95 to 98%
of the time. 100% is probably impossible to do, especially with the incomplete
knowledge the provider has. I suspect, but cannot prove, that 100% reliable
spam detection is isomorphic to the Turing Halting Problem, similar to how Fred
Cohens PhD thesis showed that malware detection is isomorphic to it)
As a data point, the only time I *almost* bit on a phish mail was from a
Latvian-language website. That I actually had an account on. In better
Latvian than mine - and I'm a native speaker.
What will a sender do, once she sees that her email is spam? Use the phone,
fax or snail mail. No software training in first place.
You're making the assumption that the same users who aren't able to understand
a non-delivery report from the remote end *will* be able to understand the
message-delayed report from their provider's end.
In your example, if the bank cannot reach you/me, it just partially locks the
account, forcing you/me to contact it and does in the meantime what is
reasonable.
And what exactly do you define as "*partially* locks"?
Pfui, new radical smtp reply code 600 Mail Was Delivered as Junk? The purpose
is to keep both sender and recipient responsible for handling false positives.
That's another case of the "say the message was delayed but deliver it anyhow"
mess we had earlier in this discussion....
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp