[Top] [All Lists]

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

2019-02-10 13:38:46

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.


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.


ietf-smtp mailing list

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