[Top] [All Lists]

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

2019-02-09 16:39:03
Hello Valdis,

if on 250-GREYLIST on retries the IP address of the client is changed, then the 
Greylist-421-retry=00:00:10 puzzle is not solved and the time begins again from 
the beginning on each IP-client-address change.  This is not in the interest of 
the sender.

The Junk folder is:
- place for the mail provider to store real spam for the recipient; and
- place for the mail provider to store false positives (no spam) for the 
recipient; and at the same time
- UI for the user to train the spam filters by moving emails in and out.

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 

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.

If a message is important and is false positive:
- if the recipient has to deal with it, the recipient has the special right to 
oversee it, forever;
- if the sender has to deal with it, there is no such special right.

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 

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.


On February 9, 2019 8:11:15 PM GMT+01:00, 
valdis(_dot_)kletnieks(_at_)vt(_dot_)edu wrote:
On Sat, 09 Feb 2019 12:53:09 +0000, ���������� ���������������� said:

I propose inserting in the draft under section ���3.  SMTP Service
Keyword��� the text:

When the service keyword 250-GREYLIST is announced, it indicates that
client SHALL keep the IP address on retries.

So riddle me this:  What then happens to an e-mail if it's next attempt
is from
a different IP address?  (Quite possible if the outbound client is a
cluster of
machines with a shared mail queue, or an HA pair that's fallen over to
the other
IP address, or....)  Perhaps this only merits a SHOULD rather than a

���If a SMTP client is rejected by the Greylisting Server during the
  session, the client SHOULD NOT attempt to start a new transaction
 during the same session and SHOULD immediately issue a QUIT command
  to end the session. ���

I do not like this text, as it is against the idea of accepting
one/few RCPT
per transaction, and telling all the other recipients ���421 ���

Agreed on that - it means that if there are multiple mail items queued
a delivery to a host that has been unreachable for some amount of time,
the client can't complete running the queue - even if the remaining
would not have been greylisted.

And if you were planning to greylist all the remaining messages, why
we using a simple '250-GREYLIST retry=00:10:00' in the EHLO response?

The PRDR-after-DATA proposal will make progress, if providers are
willing to
switch the work on dealing with spam folders to the sender.  As user
I want not
to deal with Spam folder, and this switch makes it possible.

And as a user, if the sender is doing the spam management, you *can't*
with your spam folder anymore.  Which will totally suck if the sender
decides that
since the mail got greylisted, it must be spam - and it's a false
positive on
an actually important mail like a bank notification.  Remember - spam
exist precisely because spam detection isn't perfect.

ietf-smtp mailing list

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