On 10/10/2018 5:11 AM, Дилян Палаузов wrote:
Hello,
no feedbach means either everyboby agrees, nobody understands, or
nobody cares.
Generally, a bit of everything.
I'm providing some comments because I am currently updating my DKIM
ADSP/ATPS/DMARC implementation and need to take into account the MLM
rewrite issue.
I suggested introducing
* fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3
] for sending reports on failed DKIM-Signatures, only when they align,
and
* introducing r=a in DKIM-Signature [
https://tools.ietf.org/html/rfc6651#section-3.2] that only sends
reports, when From: aligns.
This way, once an email is intenionally modifed, the modifying software
is aware that DMARC will trigger and rewrite From: so no distracting
reports will be sent.
I don't think we need a new DKIM-BASE DKIM-signature tag for what you
want. This all starts with DKIM Policy (ADSP/DMARC) restrictive
policies and receivers finally honoring them. This could be better
done as a DMARC tag extension where it provides the MLM more DMARC
mail handling information.
For example, new DMARC tag extensions "rewrite=" and "fo="
rewrite=no default, rewriting SHOULD be avoided.
rewrite=allow allow rewriting by domain with a p=none or no policy
rewrite=strict allow rewriting by domain with a p=reject|quarantine
policy
fo=da send reports when rewriting is done
Keep in mind that not every system will send reports. It is
considered a high overhead with a high redundancy. Our implementation
does not generate reports. Reporting adds a high barrier and
technical implementation requirement. Reporting should be optional
for implementation.
Also keep in mind that the idea of "Rewriting" is not a "standard"
concept. It is actually a long time mail engineering taboo to be
destroying the originating author field for any mail platform,
including RFC5322. Its a very sensitive design idea. Our MLM package
does not rewrite.
However, I am considering it now as a means to resolve the problem of
errant DMARC/ADSP domains submitting public mailings using restrictive
policies. I personally believe the DMARC/ADSP receiver can implement
ATPS "Authorized Third-Party Signers" (RFC6541) but that didn't gain
traction, so rewrite appears to be the only recourse. With more
receivers now honoring the policies, it can cause a major havoc in a
list subscription group.
Since there are more MLM systems performing DMARC-based rewrites, I
believe a better way to deal with this is for the MLM to reject the
restrictive domain submission with an email response:
"Sorry, your submission was prohibited due to a protected domain
restrictive DMARC|ADSP policy."
In fact, the MLM should stop all new subscriptions from domains using
a restrictive policy.
The rewrite should be the last thing to consider, and if it does
rewrite, it should replace the original author domain strong policy
with its own strong policy.
For example, the ietf.org mailing list has begun to rewrite and it
replaces the 5322.From with a dmarc.ietf.org domain, adds a new
X-Original-From header and resigns the message using an ietf.org
signer domain:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org;
s=ietf1;
t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=;
h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:
List-Archive:List-Post:List-Help:List-Subscribe:From;
b=.....
X-Original-From: Hector Santos <[email protected]>
From: Hector Santos <[email protected]>
What it should do is:
1) It should use a 1st party signature using d=dmarc.ietf.org to
match the new author domain dmarc.ietf.org.
2) It should has hash bind the X-Original-From header to the
signature. Since DKIM recommends not to bind "X-" headers,
a non "X-" header should be used, i.e. "Original-From:". This
means adding the header to the 'h=" field to avoid potential
mail resend exploits using different unprotected Original-from:
fields.
3) and finally, the dmarc.ietf.org domain should have its own
DMARC p=reject policy to effectively replace the one it
circumvented with the submission.
With these measures, the original author domain will still be
protected with a DMARC policy when the MLM rewrites.
That's my idea of a better approach to it as oppose to a blind,
unprotected rewrite.
I am looking for a way to get reports only when somebody
unintentionally modifies an email. The reason for this is
to have a system without unexplainable failures that makes it
easy to fix broken DKIM signing/validating software.
Remember, not all systems will send a report. I personally think a
MLM should be playing an more active role to protect against DMARC --
who can subscribe, who can submit mail. If the domain is restrictive,
it is possible to maybe only allow READ-ONLY mode and/or add a user
subscriber option that says:
[_] Rewrite the From address is allowed
Although, it could just use the DMARC record to see if there is a
"rewrite=no|allow|strict" option. The MLM is now doing the DMARC
lookup, so its possible now to add this logic.
if rewrite=no then
send submission/subscription prohibited message
if rewrite=strict then
if the mlm has no dmarc policy, then
send submission/subscription prohibited message
else
do rewrite with new matching signer and author
if rewrite=allow then
do rewrite with new signer and author
if rewrite= then // no tag
follow local mlm policy setup
How about introducing fo=da for sending reports on failed
DKIM-Signatures, only when they align? This is much like having r=a
in DKIM-Signature that only sends reports, when From: aligns. This
way, once an email is intenionally modifed, the modifying software is
aware that DMARC will trigger and rewrite From: so no distracting
reports will be sent.
I'm currently updating my DKIM implementation with DMARC
ADSP/ATPS/DMARC, which basically means adding the local policy
switches to finally honor the p=reject/quarantine policies.
This means that our MLM needs to do much of the above which is basically:
1) During new subscriptions, check for restrictive domain.
2) During list submissions, check for restrictive domain.
(_) Don't allow, send notification
(_) Allow rewrite with address ________________________
[_] Optional check for DMARC 'rewrite=" extension
The main design consideration is to make sure the list submission is
either prohibited or corrected before the distribution and reaches
DMARC receivers.
--
HLS
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
