On Wed 08/Jul/2020 10:21:15 +0200 Dotzero wrote:
On Tue, Jul 7, 2020 at 2:19 PM Alessandro Vesely <[email protected]> wrote:
On Tue 07/Jul/2020 18:27:40 +0200 John R Levine wrote:
There's a distinction though. ARC tells you "that guy over there said the
original message passed", and you have to trust it. On the other hand, the
transformations draft, when it works, hands you the original message, and
you don't have to make that trust assessment.
I understand that, and I still don't see why it's useful.
At what overhead cost? You have to hold the connection open while reversing
the transformations or you are not in a position to reject (vs accepting
then rejecting). There are folks currently holding the connection while
evaluating the DKIM signature but that is lighter weight than reversing the
transforms AND doing the DNS lookup to validate the DKIM signature.
In principle, reversing the transformation shouldn't be more complicated than
verifying a signature with l=. Skipping the subject tag while canonicalizing
the header is not much more work than adding \r to each line (at mine, lines
are terminated by a bare \n.) The addition of an entity may require to skip an
initial part of the body, and then stop at the corresponding boundary. It can
be considered a refined canonicalization, negligible w.r.t. cryptography.
It would allow me, for one, to honor remote DMARC policies. Of course,
I'd still need to manually whitelist non compliant MLMs. However, when
the number of those drops below a reasonable figure, whitelisting might
become feasible. >>
An interesting dependency. When might that reasonable figure occur? What is
a reasonable number? Would other receivers agree with you on
reasonableness? Should a standard be predicated on this basis?
Nowadays, I honor remote DMARC policies on a few domains only, (paypal, amazon,
and the like.) I cannot switch to the opposite behavior, to honor DMARC
globally except for a few exceptions, because From: rewriting is considered
dirty and there is no other way for MLMs which need to have a footer. IOW,
DMARC is broken.
If we predicate a standard which makes it possible for MLMs to comply, then
honoring DMARC becomes possible. MLMs which don't comply can result in missed
messages until receiving MXes whitelist them. Those glitches are justified
because the culprit is the MLM in that case, not the MX. When there are enough
examples of working mailing lists, that kind of explanation may sound
acceptable to users.
It's hard to imagine a realistic situation where a recipient system
would strip off the changes and show the original message, so the
recipient has to trust that the mediator doesn't make malicious
transformations. >>
Agreed. Undoing the changes has to be done on a temporary file, solely
for verification purposes. Undoing the changes would be illegal, if the
footer contains legal claims. >>
Your claim is interesting. What possible legal claims might an
intermediator make that would be legally binding on a receiver and be
illegal to undo in a temporary file for processing? Are you a lawyer? Are
you a lawyer making such an assertion for all jurisdictions?
IANAL, but I heard that argument by MLMs holding they cannot just omit any
changes because blah blah. There are also forwarders who want to add
disclaimers or spam reporting directives as a footer. Tampering with the mail
they send sounds likely to be an offense in a number of countries. Of course,
the same allegation can be made about the transformations they applied in the
first place. However, MLMs should have managed to get subscribers consensus to
do so.
To endow a message with instruction to revert transformations should not imply
an authorization to deliver the message with those transformations removed.
The deal should be to supply that data for signature verification *only*.
So if you trust them that far, why wouldn't you also trust them to
report the status of incoming mail? >>
I cannot trust ARC operators, unless I manually compile a trusted list,
which is as unfeasible as whitelisting each MLM. >>
Or you use a trusted list compiled by someone else. The use of blocklists
such as Spamhaus ones or RPZ come to mind.
Yeah, I use both those blocklists. I also use dnswl, which actually can be
configured as a filter to prevent applying DMARC policies. I only use it to
prevent SPF reject-on-fail. The difference between SPF and DMARC is that the
former has other means to do the right thing, so that dnswl works as a second
level savior.
The standard should describe a few (deterministic) ways to be DMARC compliant.
At the moment we only have From: rewriting, which is not even specified. I
proposed to use To: instead of From:, which would be interesting to experiment.
Murray's transformations is yet another way, particularly nice as it would
allow mailing lists like this one to resume working the way they used to.
I trust the original message as any other message. Allowed
transformations are designed to not pervert the original message.
Consider my notes 1 and 2 about l=, in a message upthread[*]. We can also
specify limits on the size of subject tags and footers. Transformations
that insert stuff before the original content should not be allowed
—rewrite From: in such cases. >>
This is getting unduly complicated. Now we have to hold up progress on the
effort while folks argue out what the size limits on subject lines and
footers should be?
It should not be allowed to insert text long enough (including trailing spaces)
to push the original subject out of view. I don't think determining this
number is the hardest part of the spec.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
