[Top] [All Lists]

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

2019-02-10 15:07:05

On Sun, 2019-02-10 at 14:25 +0000, Paul Smith wrote:
On 10/02/2019 12:07, Дилян Палаузов wrote:
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

If the meeting is important, then you need confirmation. Either ask the 
recipient for confirmation, or use another medium (eg telephone) where 
confirmation is implicit. If you send an email asking for confirmation 
and you don't receive confirmation, then you need to follow up the email 
in some way.

WHATEVER you do with email (just as with post, SMS, carrier pigeon, 
etc), if you don't ask for confirmation, then you don't know if the 
recipient has received the message (and agreed to the meeting) or not.

Irrespective of the importance of the meeting, if you ask for confirmation, the 
confirmation can be again false
positive.  Shall be there a confiramation, of the confirmation?  Where does the 
loop end?

If the recipients servers have rejected the message, I know it was not 
received.  Otherwise I want to assume the message
was properly delivered.

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.

Argeed.  Let’s do things one by one:

In the simple case where a sender writes an email to a single recipient, and 
the server decides the email is spam, but
the sender and recipient (possibly) think that the mail is ham (false 
positive), the options are:
-- deliver the email in the Junk folder, after DATA say "250 It is my honour to 
accept your message"
-- reject the email at SMTP level after DATA, telling the sender in the 
DATA-dot reply that this email is not going to
be accepted, possibly ellaborating more on this.
-- communicate to the client:
  599-Your message was delivered in the spam folder of the recipient.  Tell the 
  599-offline to mark your email as ham, so that future emails from you are 
  599 directly in recipient's Inbox...

What is valid, what is not acceptable for a single recipient case?

Is it acceptable if the recipient can tell its provider, in case of doubt, for 
an email only to that recipient, that the
provider has to:
  - reject at SMTP level the message, possilby inserting in the reply text 
provided by the user (e.g. PO box, fax and
phone number);
  - accept the email in the spam folder;
  - accept the email in the spam folder and communicate over 599-after-DATA 
reply, that the the email was put in the
spam folder, including also text provided by the user?

Once this is clarified, the discussion will go for the cases, where the mail 
has more recipients.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>