Hello Valdis,
I described a case, where an ordinary meeting invitation was delivered in the
Junk folder, read in turn two weeks later
and because of this the meeting has not happened. Please propose what can be
done in order to avoid such things in the
future.
On Sat, 2019-02-09 at 19:39 -0500, valdis(_dot_)kletnieks(_at_)vt(_dot_)edu
wrote:
On Sat, 09 Feb 2019 23:38:15 +0100, said:
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)
The provider cannot distinguish between false positives and spam. The user has
to do this work. The question is: which
user - the one who writes, or the one who reads.
Compared to DMARC, with p=quarantine the domain owner states, that the
recipient has to deal with suspicious emails,
while with p=reject the domain owner states, that it wishes, that the senders
deal with suspicious emails. The
recipient is not bound to the preferences on the domain owner and can decide in
all or in none case do the extra the
work.
This applies for spam, too. What is wrong, if each recipient (mailbox owner)
can decide, whether the recipient or the
sender has to deal with emails, evaluated by the provider as likely spam?
Currently this is not possible (done), and one of the reasons is that users are
stupid. Yes, if the users are stupid
and cannot agree on a meeting using emails, because design decisions made by
the providers based on stupid users, there
is a vicious circe.
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.
I speak about users who can understand both messages. If a user cannot
understand a message, ... you propose that this
message shall not be delivered in first place.
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"?
E.g. lock only the online banking interface, or lock your card for online
payments, or do investigations in address
registers about new physical addresses. This happened actually to me, when
mailmen messed things and returned to the
bank physical envelopes as non deliverable. This goes now out of SMTP domain.
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....
The purpose of the discussion is to avoid overseeing emails, that the provider
classified as very likely spam, but which
messages are in fact ham. I described problems in the way SMTP currently works
(is applied) and proposed how these
problems can be approached. My suggestions replace one problem with another
problem. Criticizing me, that I propose
new, problematic approaches, without seeing what gets better, leads nowhere.
Let’s see now how shifting the work on dealing with false positives from the
recipients to the senders works in
practice, and if this can be constructive:
When I click on emails on this mailing list on Reply-All, my answers go
sometimes directly to hsantos(_at_)isdg(_dot_)net . From
there I got on 7 Feb 2019 07:19:01 GMT, 6 Feb 2019 21:48:22 GMT, 5 Feb 2019
21:03:41 GMT non-delivery reports stating
The original message was received at Thu, 7 Feb 2019 07:19:01 GMT
from x2f3b179.dyn.telefonica.de [2.243.177.121]
----- The following addresses had permanent fatal errors -----
<hsantos(_at_)isdg(_dot_)net>
(reason: 554 IP 144.76.142.78 Rejected By System Policy Filter)
----- Transcript of session follows -----
... while talking to mail.isdg.net.:
<<< 554 IP 144.76.142.78 Rejected By System Policy Filter
554 5.0.0 Service unavailable
Likewise, my answers are supposed to go sometimes to
johnl(_at_)taugh(_dot_)com, and these were returned on 7 Feb 2019 22:20:32
GMT, 6 Feb 2019 22:11:56 GMT, 5 Feb 2019 08:06:47 GMT with:
The original message was received at Wed, 6 Feb 2019 22:11:56 GMT
from x5d877ef8.dyn.telefonica.de [93.135.126.248]
----- The following addresses had permanent fatal errors -----
<johnl(_at_)taugh(_dot_)com>
(reason: 553 Blocked due to excessive spam. Contact
hostmaster(_at_)iecc(_dot_)com from another network if it is fixed.
Requests without the specific IP address will be ignored.)
----- Transcript of session follows -----
... while talking to mx1.taugh.com.:
RCPT To:<johnl(_at_)taugh(_dot_)com>
<<< 553 Blocked due to excessive spam. Contact hostmaster(_at_)iecc(_dot_)com
from another network if it is fixed. Requests without
the specific IP address will be ignored.
550 5.1.1 <johnl(_at_)taugh(_dot_)com>... User unknown
DATA
<<< 553 Blocked due to excessive spam. Contact hostmaster(_at_)iecc(_dot_)com
from another network if it is fixed. Requests without
the specific IP address will be ignored.
What is the problem with the IP 144.76.142.78 or the emails as whole? Is it
better, if I am aware that the mails were
not delivered, rather than delivering the emails as junk and not reading them?
Obviously the answers of those quesions, the actions taken, consequences and
alike, do not depend on having the
possibililty to apply different delivery policy per recipient.
Regards
Дилян
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp