On 4/16/2015 8:16 PM, Scott Kitterman wrote:
+1 Extremely bias.
Lets keep in mind that there are two minimum receivers generally with
a MLM transaction that also need to be part of the cost and impact
analysis:
MDA1 -- receiver and resigner
MDA2 -- final user(s) receiver(s).
Another solution (partial) is for MDA1 honor policy and not allow
resigning to take place. The one that is talked about the most are
the MDA2 end user receivers rejecting messages. We will want to
maximize the MDA2 consistent and persistent result factor since there
could be many different implementations at the MDA2 nodes.
It's a bit more complex than just not resigning (actually resigning shouldn't
hurt).
What I meant about actually, is for the MDA1 to respect the
restrictive policy and reject the message (list submission,
subscription attempts, etc) and use a reply code/response to explain
why.
What MDA/MTA1 needs to do is avoid any transformations that would invalidate
the originator's DKIM signature.
Thats optional. Again Domain Policy based:
Policy is relaxed, the MLM may resign, including stripping.
Policy is strict, the MLM should block the subscription/submission.
Again, as long as the policy also give options for the 3rd party, it
can satisfy all boundary conditions. See below.
For some, that's a reasonable solution, but for others it's not because they
aren't willing to give up the traditional mailing list transformations, i.e.
there is a side effect that leads the mediator to consider the approach to
costly (costs aren't just money).
Scott, when it comes to products, you will have all sides and the good
way to address is to make it optional. Everyone is happy. Sure, its
more work, but thats the life of a product developer.
So yes, we need to separate all the subjective, possible
Administrator/Operator options, local policy related stuff and extract
the basic protocol engine stuff, the state machine. If you control
the access points, then much of this is resolved. See below.
I'd still rather focus on an assessment framework before we go zooming into
solutions again. I don't think we're getting very far without it.
We went thru a threat analysis (RFC4686) and functional requirements
(RFC5016) RFC productions and have the basic ideas and problem points
well understood.
At the end of the day, no matter what, the receiver will have a fixed
set of boundary conditions regarding what the ADID and SDID will look
like. There are nine basic combinations of signatures when you assign
to each NEVER, ALWAYS, OPTIONAL expectations:
1st party: NEVER, ALWAYS, OPTIONAL
3rd party: NEVER, ALWAYS, OPTIONAL
So your protocol engine needs to be able to deal with each combination
of possible policy. Some will fold providing a smaller set of
conditions. The following is an example diagram illustrating this:
+-----------+
| PAYLOAD |
+-----------+
|
v
+----------------+
| | +------------+
| DKIM |--------------------------->| CONTINUE |
| Signature | UNSIGNED: OPTIONAL (1) +------------+
| Authorization |
| Protocol |
| | +------------+
| |--------------------------->| |
| | SIGNED: EXPIRED (2) | |
| |--------------------------->| |
| | NO MAIL EXPECTED (3) | FAILURE/ |
| |--------------------------->| CLASSIFY |
| | UNSIGNED: REQUIRED (4) | |
| |--------------------------->| |
| | SIGNED: NOT EXPECTED (5) | |
| |--------------------------->| |
| | 3P SIGNED: NOT ALLOWED (6) | |
+----------------+ +------------+
|
|
SIGNED
MESSAGE
|
v +------------+
+--------------+ | CONTINUE/ |
| |--------------------------->| CLASSIFY |
| | INVALID SIGNATURE +------------+
| DKIM |
| SIGNATURE |
| VERIFICATION | +------------+
| (7) |--------------------------->| PASS |
| | VALID SIGNATURE +------------+
+--------------+
No matter what system you have, they all have be persistent and
consistent on what is expected for each condition. That is not a
mandate (you have local policy), but it tells you what are the MUSTs,
SHOULDs and MAYs.
Overall, you are looking for the failure points.
(1) Unsigned mail arrives and the policy says its optional.
Indeterminate condition, punt, continue.
(2) Signed mail, but it expired. Negative classification.
(3) No mail is expected for this domain, Negative classification.
(4) Unsigned mail arrives and the policy says its required. Negative
classification.
(5) The main is signed, but it wasn't expected. Negative classification.
(6) The mail is signed by 3rd party and policy doesn't allow that.
Negative classification.
While some of the conditions can be folded, we are missing #6 which
allows for checking for 3rd party signature authorization. But it can
even be just that you don't expect it, hence a condition that allows
for strong failure detection.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
