ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] SMTP Greylisting Retry Hints + PRDR

2019-02-10 11:06:02
On 2019-02-10 12:07:45 +0000, Дилян Палаузов wrote:
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.

Yes. And as far as I can see you haven't demonstrated how anything you
have proposed in this thread reduces the probability of this happening.

This is possibly because you have proposed for at least three or four
different mechanisms in this thread (not all of them related to the
subject) and I at least have a hard time keeping track of what you are
currently talking about and what it is supposed to accomplish.

It might help if you concentrate on this single scenario and describe in
detail what the sending person, the sender MTA, the recpient MTA and the
receiving person should do in you opinion and how it differs from what
is possible (or common) now.


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.

The one who writes will always claim that their message isn't spam.


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?

Nothing.

Currently this is not possible (done),

Of course this is possible, and it is also done (we did until recently).
It just isn't very common.

and one of the reasons is that users are stupid.

Not necessarily stupid, but generally not interested in the technical
details. Other reasons are that giving users more knobs to turn results
in more support calls (and hence higher cost), and that other
organization's software (which you have no control over) may not deal
with it gracefully.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp(_at_)hjp(_dot_)at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>