Mr. Gomez,
Traditionally, many in the IETF and the mail industry had an aversion
towards strong deterministic transport (system) level filtering ideas.
This is burned into RFC2821/5321:
7. Security Considerations
7.1 Mail Security and Spoofing
This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail.
The text different between 2821 and 5321 is that the "user" is no
longer "ignorant."
Many preferred to pass the buck to the user for making decisions on
what is considered accepted mail. The DMA, the "Spammer" world, good
or bad, want you to ACCEPT the mail to pass to the user. CAN-SPAM
also plays a role here too in the area of User Vendor contracts.
So in general, whenever we had new strong deterministic rejection
protocols, we had the friction of dealing with "ACCEPT/SEPARATE" or
"Quarantine" ideas embedded as well as means to reduce the potential
false positive nature of rejection policies.
Case in point with SPF.
SPF had a strong REJECTION concept with RFC4408 and with the latest
spec RFC7202, it was relaxed with allowing for quarantining ideas
(mail separation). RFC7208 made RFC4408 more costly by adding more
complexity for an "ACCEPT/SEPARATE" mode of operation for failed SPF
messages as opposed to just REJECTING failed SPF messages.
Part of the problem is that the idea of quarantine does presumed a
backend mail storage design that mail separation was even possible.
It is not an universal concept to have this multiple mail folders
idea, ability and/or MUA/UI infrastructure for end-users. So in that
vain, it does come with a high support and also high implementation
cost to include Mail Quarantine functionality into a specification.
REJECTION is a must lower design implementation cost.
In theory, rejection or quarantine, both must provide the same end of
result of protecting users from harm and also the domain from being
exploited. If you are going to quarantine mail instead of rejecting
it, then you need to make sure the USER does not get the mail
directly in the natural in-box, including the POP3 mail stream -- it
must not be part of the pick up.
--
HLS
On 3/25/2015 3:17 PM, J. Gomez wrote:
On Tuesday, March 24, 2015 10:08 PM [GMT+1=CET], MH Michael Hammer (5304) wrote:
On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote:
... and again, if those decisions result merely in rejecting a
message, the user isn't involved, but as soon as those decisions
can result in tagging a message for possible consideration by the
user (probably via different display by the UI), we can't ignore
the user.
I agree that this isn't the place to delve deeply into user
behaviour and UI design. But we shouldn't ignore the context of
our work.
+1
Email is for the users. p=quarantine is a USER PROBLEM.
No, p=quarantine is a problem WE cause.
Yes, but a problem that ultimately the user gets directly planted before his
eyes, and which the user has to roll up his sleeves to deal with as well/bad as
he can possibly manage.
Translation: p=quarantine has vey high support costs.
As I understand it, in the beginning of the coming up with DMARC, p=quarantine
was designed as a stepping stone in the journey towards p=reject. In that view,
the high support costs of p=quarantine were tolerable because p=quarantine was
meant to be a temporary situation for the sender domain Owner. Now that
p=reject is a dead end for all practical purposes, p=quarantine has less and
less utility. Only p=none is safe to use unless you do not have real people as
users.
We must work hard to find a solution which makes p=reject a viable setting
which can be reliably relied on.
Regards,
J.Gomez
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
