On 2/10/2019 12:05 PM, Peter J. Holzer wrote:
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.
+1
It sounds to me he is looking for UI-controls here:
"Hey {USER.NAME},
You got a message from sender {RETURN-PATH} which is temporarily
being blocked due to a system-wide GREYLIST policy.
If this is a legit sender, you can do nothing and receive
the message shortly when it is resent.
If the mail is not resent, it was most likely, a spammer.
If you wish to white list this sender now, you can click this
link to avoid greylisting this sender in the future. Note,
it will not white list the sender for all users, just to you.
If you know this is a Bad Guy, you can black list the sender
right now. Note, it will not black list the sender for
all users, just to you."
and all the variations of this including confusing IP data, etc, etc.
SMTP-GREY can apply before DATA and at DATA. If at DATA, it was always
possible to show the user the message before it is "officially" SMTP
accepted (during the block time). In fact, when the radical idea of
intentional greyListing clients was first implemented in 2003, there
was an unsureness about this radical idea. This was especially true
with many IETF folks -- no way were going to endorse this
"Greylisting" SMTP concept. That changed by 2012 when I wrote the
draft. But this was the main reason for capturing the payload at DATA
in order to have gain operator confidence just in case legit mail not
being retried and they could manually import it into the mail
database. Of course, the proof of concept was shown: Good SMTP systems
do retry per SMTP requirement, Bad SMTP systems do not and ince the
confident was high with the concept, the only thing left was to make
sure there was purging of a now high accumulation of payload files on
a regular basis!
Over the years, there were times when I had a new service sign up and
I know I will get be getting a confirmation email. So I will do one of
the following:
- Just wait until the retry is done and the mail is accepted.
Not concern about time here.
- I can't wait, a greylist occurs and I read the stored payload,
get the URL confirmation link or code to entry at some GUI.
I don't worry about the official reception of the email
eventually arriving. Fortunately, systems have not connected the
two ideas yet -- using an official email SMTP acceptance with
a GUI confirmation process.
- Anticipating the new service email address will be a common email
and domain to be received, I'll add the domain to a white list.
I don't like doing this white listing when it is not IP protected.
None of this is within the "scope" of this SMTP-GREY draft, in my opinion.
But of course, developers could and should keep those user vs
system-wide policy ideas in mind when implementing or enhancing their
existing greylist system. I don't think the draft prohibits these
advanced SMTP-GREY implementations.
Advanced systems can do many things with a captured payload, including
adding SPF/DKIM/DMARC into the Greylist equation and I suppose they
can do things like the above notification at the UI level.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp