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
training.
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
reasonable.
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.
Regards
Дилян
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
the
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
SHALL?
���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 ���
retry=0���.
Agreed on that - it means that if there are multiple mail items queued
for
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
messages
would not have been greylisted.
And if you were planning to greylist all the remaining messages, why
aren't
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*
deal
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
folders
exist precisely because spam detection isn't perfect.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp