Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 20 06:00:05 2020

2020-09-20 Thread Benny Pedersen 

John Levine skrev den 2020-09-20 11:59:

Count|  Bytes |  Who


next weeks lotto ?

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

2020-09-20 Thread Alessandro Vesely 

On Fri 18/Sep/2020 15:17:53 +0200 Joseph Brennan wrote:

or don't use p=quarantine and p=rejectKeep it simple



Publishing an actionable policy is not just a question of simplicity.  It 
conditions the very semantics of DMARC.


OTOH, MLM transformations break signatures irrespective of From: rewriting. 
Perhaps, we should make it more clear whether the "MLM problem" consists of the 
inconvenience of having From: rewritten rather than the inability of verifying 
the original author domain signature.


At any rate, the two drafts referenced below propose methods to validate the 
original domain.  At that point, the original From: can safely be restored.


Considering that both methods have to rely on additional stuff passed in the 
message header, the two methods can be viewed as strikingly similar to each other.



Best
Ale




On Fri, Sep 18, 2020 at 5:47 AM Alessandro Vesely  wrote:

On Thu 17/Sep/2020 21:11:42 +0200 Sabahattin Gucukoglu wrote:


Wouldn’t it be nice if you could ask for MLMs to transform, just using a
DMARC policy, even p=none, so that you could test with a live environment
containing MLMs that work around DMARC policy? Or you could ask for *no*
transform, even for p=quarantine or p=reject, so that your DMARC policy can
be used to legitimately restrict usage to directly-sent email?



It may be practical to place the asking in the message header, rather than
in the DMARC record.  That way, senders can specify their wish on a
per-message basis, presumably based on message recipients.  Note that a
request to transform can include information about how to reliably undo the
transformation, thereby verifying the original DKIM signature as described
in dkim-transform[*].  Possible strategies that senders might use could be
similar to those for putting weak signatures[†].


Best
Ale
--
[*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform
[†]
https://tools.ietf.org/html/draft-levine-dkim-conditional-04#section-4.1
























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 20 06:00:05 2020

2020-09-20 Thread John Levine 
   Count|  Bytes |  Who
++---
  4 (19.0%) |  59259 (32.1%) | Douglas E. Foster 
  4 (19.0%) |  34450 (18.7%) | Joseph Brennan 
  2 ( 9.5%) |  20361 (11.0%) | Jesse Thompson 
  2 ( 9.5%) |  12570 ( 6.8%) | Kurt Andersen (b) 
  2 ( 9.5%) |  11447 ( 6.2%) | Sabahattin Gucukoglu 
  2 ( 9.5%) |   9262 ( 5.0%) | Alessandro Vesely 
  2 ( 9.5%) |   7723 ( 4.2%) | John Levine 
  1 ( 4.8%) |  15078 ( 8.2%) | Ken O'Driscoll 
  1 ( 4.8%) |   9022 ( 4.9%) | Dotzero 
  1 ( 4.8%) |   5498 ( 3.0%) | Kurt Andersen (IETF) 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc