On 6/14/2019 5:58 PM, Дилян Палаузов wrote:
Hello Ken,
effectively I proposed handling p=reject and p=quarantine the same way.
..
Lets have an example for p=quaranite:
majordomo@domain is an address where commands are sent and the software
receiving the
command always sends an answer, even if the command is unclear. An email is
sent
to majordomo@domain. The sending domain has published policy Quarantine.
This address
has no spam/junk folder attached to it. The options for an email are:
* reject the email during the SMTP dialog
* accept the email and let majordomo send an answer to it
* arrange a human to decide which emails to discard (handle an imaginary Spam
folder for the account).
Oh I see your concern/point/proposal now.
Yes, I highlighted this basic issue in years past in regards to the
handling semantics debates. Even with SPF, how -ALL (FAIL) was
interpreted and handled was questioned. Some believed a -ALL FAIL
policy is more like a quarantine because "no one actually rejects."
But overall, this would be an implementation consideration, not a
protocol design consideration. The protocol is correct to have a
handling semantics describing both ideas - reject and quarantine.
All we can do is highlight the existence of backend mail storage
designs and legacy MUA protocol(s) that can not handle a quarantine
safely. So at best, you can basically highlight the security design
concerns and possible requirements to implement a quarantine concept.
There is much mail design history and evolution to consider. The
concept of quarantine came with the integrated mail design premise that:
- The backend offers user folders or separate mail streams for normal
in-box mail and quarantine, spam, junk mail separations. While this is
common today for ESPs, this was not always the case for all backend
designs. It was often proprietary in nature. No standard here unless
we assume everyone using an "Microsoft Exchange" (MAPI) concept or
IMAP which is not reality. This coincides with the premise,
- The broad range of online and offline MUAs all support the
multi-folders provided by the backend. This is again not reality and
not always the case.
I'll give you a perfect example -- POP3.
POP3 is a single mail stream pick up protocol standard. So for a
backend that provides POP3 service available to its customers and for
the user using MUA with POP3 support, the backend POP3 server MUST NOT
merge any suspicious, spam, junk or quarantine mail with the user's
normal in-box mail pick up stream.
While an advanced POP3 backend server can emulate a single stream
consolidation of multi-user folders, it would a major security loop
hole to expose POP3 users to quarantined mail merged into the user's
pop3 mail stream. For this to work securely, this advanced POP3
server must assume the MUAs are advanced enough or users are advanced
enough to write MUA scripts that will separate the single pop3 stream
into spam, junk and quarantine folders again.
All we can do is highlight how "rejects" can be interpreted
differently. After much discussion with SPF, while it didn't provide
an specific example using POP3, it was generically described under
Local Policy Considerations:
https://tools.ietf.org/html/rfc7208#appendix-G.2
It should also be highlighted for DMARC-bis, if not already.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
