-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>A legacy forwarder that is not DKIM2-aware and performs SRS rewrites the
>envelope MAIL FROM, as it has done for many years to preserve SPF across
>forwarding.
SRS is not documented in any RFC, so from the IETF's point of view it is
anyone's guess what is going on ...
... but I believe it be commonly accepted that the forwarder will not
use the MAIL FROM which was used to send the message to it but will
instead ensure that an SPF lookup on the domain part of the MAIL FROM
that it is using will get a "pass"
Note that this will not be an "aligned pass" so it will not help you
with DMARC ... it's only useful when talking to receivers who insist on
any kind of SPF pass
>It does not receive a broken message; it breaks a good one, by doing
>exactly what SRS has always done.
You are correct ... a naive system that receives a perfectly good DKIM2
message and transparently forwards it, changing nothing but the RFC5321
MAIL FROM, will not be able to send it to a DKIM2 aware destination
So we should probably put a sentence into the BCP telling people not to
do that ! except that if they are not doing DKIM2 I wonder if they
would ever read it.
Now you might think that because of the other (totally undocumented in
the way that the IETF would understand it) parts of the SRS string that
a receiver could reconstruct the previous MAIL FROM ... if you want to
go down that route then you would block publication of DKIM2 as we
waited for SRS to be properly documented (if indeed there is any
consensus on the detail, and whatever caused it not to be documented in
the first place is not still a show-stopper).
I think that documenting SRS to be able to leverage what it reports is
likely a waste of a considerable amount of time.
Instead, upgrade the system that is using SRS to only send it to the, I
believe, relatively small number of receivers who consider an unaligned
SPF pass to be of value... or better yet, upgrade the system to be DKIM2
aware and then you can declare that you are doing SRS and provide
attestation (including the "invisible hop" stuff if you need it) that
your actions are cryptographically sound.
>Structurally this is the same as a non-DKIM2
>list rewriting a Subject:
not really ... we've got some robust documentation (that will shortly be
available at "standard" level) for header fields
>The claim that forwarding is negligible by volume mistakes what forwarding is.
>It is not a class of sender that appears as a line on a dashboard
I assure you that it is at $DAYJOB$ ... and quite a long way down...
Also when customers report that forwarding is failing (either to our
system or away from our system) we strongly encourage them to use IMAP
to collect their email from their <n> accounts (something modern
software does out-of-the-box) rather than forward email through one or
more systems to one central location. Spending our time persuading
remote systems to reconfigure to deal with edge cases in forwarding is
generally ineffective -- and systems that forward to us without any
effective controls on volume or content rapidly find that their flows
are throttled or disabled altogether.
So yes, I will agree with you that forwarding does occur and the people
whose email is forwarded place value in that happening. However, to
suggest that it currently works extremely well and DKIM2 is going to
make the situation worse does not accord with what I see going on.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBapBJt2HfC/FfW545EQLaWQCdEKCZcLEQWp7GpFgR+FxraWrvW7wAoOvb
VLRDV1TJYmWc+x0veO0ASbVx
=vsDk
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
