Hello Paul,
I am suggesting to tell the sender that the message for a recipient is
temporary rejected, why delivering the message.
Why would an mta-client change the message-id of an email having several
recipients on each retry?
Consider this example, I wrote to a friend an email stating “Tomorrow is my
last day in this neighbourhood, I would enjoy meeting you once again before my
departure”. This email had empty Subject: and two weeks later the recipient
told me, that she read only now the email, because it was delivered in the Spam
folder (quarantined). In this example, the software/AI/ML decided that there
will be no meeting. The real term is “false positive”.
To avoid side effects of false positives, somebody has to be involved in
manually dealing with them. You have to involve the recipient, the sender or
special staff.
Obliging the recipient to deal with false positives, leads to a cancelled
meeting in the example here and it “is nobody’s fault”. Besides, when the
recipient address is an alias for a mailbox on another provider, there is no
way the aliasing server can communicate to the recipient the suspicious state.
Having special staff to deal with false positives is not an option in my case.
So the senders must be concerned with false positives, by hard rejecting the
email, what I proposed.
There is no ideal way to go. If the options are:
- good delivery for a server with a lot of aliases to other service providers,
by ensuring good IP-repitation (implies no-bounces policy),
- no cancelled meetings or alike, because the software decided to speed down
the communication flow by quarantining a message (false positives),
- mail delivery with unnecessary delays
you have to choose your priorities. Any choice has drawbacks. Arranging
software towards avoiding the impacts of false positives (meetings, which do
not happen) is justified.
Corollary: avoiding quarantines at any price, e.g. by rejecting emails with
p=quarantine, when DMARC fails, can be justified depending on the priorities.
Regards
Дилян
On February 8, 2019 10:37:56 AM GMT+01:00, Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
On 07/02/2019 22:20, Dilyan Palauzov wrote:
Strictly speaking the delivery for all recipients does not have to be
delayed. The server can deliver promptly the messages to all deserving
recipients, memorize the Message-Id and the per recipient response, and
in subsequent transactions communicate the status per recipient.
So, you're suggesting delivering the message to the recipient, even
though you've said it's been rejected?
That's not standards compliant... You don't KNOW that the sender is
going to retry it, and if it does, you don't know if it'll use the same
Message-Id, so the recipient may receive a message that the sender
thinks they didn't, or they may receive multiple duplicates, or
something else. You can't deliver it until/unless you say you'll
deliver it.
The problems with the idea of 4xx rejecting recipients with different
rules are that you really don't know what the sender is going to do,
you
are essentially removing the ability to send mail to multiple
recipients
at once, and you are adding load everywhere - a message sent to 100
people at the same domain potentially has to be sent 100 times rather
than just once (even if all recipients will accept it), and there have
to be 5050 recipient checks rather than just 100, etc.
Is it that big a deal? If the recipient doesn't want the message, just
accept it and quarantine it... That'll may even cut down on support
calls - when a message is sent 'To: bob(_at_)example(_dot_)com,
kate(_at_)example(_dot_)com',
and Kate receives the message, but Bob, who is sitting next to her,
doesn't and has no idea why because you PRDR rejected it because of a
rule that Bob turned on and didn't understand. (Or doesn't receive it
until a few hours later (if at all, if the sender times-out), because
he
HASN'T got a *relevant* rule enabled, but does have some irrelevant
slightly different setting from Kate).
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp