-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <19ed7d7986f.5a1d65d93177986.1981876181637172746@wadevelopmen
t.co>, William Weiner <[email protected]>
writes
>Such services act as Sender ADMDs in DKIM2 terms. They sign outbound messages
>from
>their own domain (m=1) and bear full accountability for those messages. The
>absence of
>a prior chain is a design property of this deployment pattern, not an anomaly.
>This
>applies equally to services that emit per-recipient body variants from a
>single
>inbound
>message, for which there is no single message instance to chain from.
ie a brand new message is created ...
>Privacy-preserving re-originators SHOULD:
>
>o Sign all outbound messages with a DKIM2 signature from their own domain,
>with
>strict DMARC alignment (p=reject or p=quarantine).
>
>o Include an opaque nonce field (for example, a keyed hash of the inbound
>message
>identifier) as a lookup into their own records, so that they can respond to
>legitimate accountability queries without disclosing sender identity in the
>message
>itself. A nonce that maps to a record past the service's retention window is a
>transparency statement: the underlying message is gone by design and the
>service
>can say so.
You don't need to put your tracing value into a DKIM2-Signature; you
could put it into a header of your own design ....
>o Strip Received headers, rewrite Message-ID, and rewrite References and In-
>Reply-To
>to their own domain namespace, to prevent originating-system identifiers from
>propagating to recipients across the re-origination boundary.
this is now such a "new message" that it is indistinguishable from one
that originated on your system and has no back-story at all
we don't find it necessary to say "systems may create messages where
nothing existed beforehand" ... so what it is the need to say "if you
want to wipe what happened before the latest sending event then feel
free"
>o Publish a machine-readable relay policy declaration on their sending domain
>(see proposed mechanism below).
sorry.. mailbox providers are going to judge your system on whether it
is sending messages that their users want to receive at the particular
time they arrive. If you don't do that then your deliveries will be
throttled or blocked and no machine-readable anything will change that
>--- Proposed addition to Section 6.3 ---
>
>Add after the first paragraph:
>
>Receiver ADMDs SHOULD NOT treat the absence of a DKIM2 chain as evidence of
>evasion
>or abuse when the sending domain carries a valid DKIM2 originator signature.
how would they know you were relaying email unless you told them ?
>Receivers SHOULD treat messages from declared privacy relays (see proposed
>mechanism
>below) equivalently to messages from any other Sender ADMD. Receivers SHOULD
>NOT
>apply
>adverse disposition solely because no prior chain is present.
again ... most person-to-person email will have a single DKIM2-Signature
field. most business-to-consumer email will have two DKIM2-Signature
fields both applied by the same machine at the same time.
if your email has just one DKIM2-Signature then it is nothing special
>A privacy-preserving relay operates under a service agreement with the
>subscribers
>who direct their mail through it. Adverse treatment of the relay's output does
>not
>identify bad mail -- it penalizes the recipient's deliberate choice about how
>to
>receive their own email.
ah ... if you are one of those services that receive email on behalf of
someone and then sends everything through to a large mailbox provider no
matter the quality then
a) your customers will forget themselves and mark spam as spam and since
it is your sending reputation on the line, that will suffer, perhaps
very quickly;
b) your customers will find that automated systems will identify low
quality email and ding your sending reputation; they will spend their
time waiting for email because it has been deferred, or hoicking it out
of the spam folder because the automation concludes that on average that
is the best destination for it;
c) you should give up forwarding and start providing IMAP services; most
of the apps (and desktop software) can easily fetch mail from multiple
services in parallel and merge the mail into a single user experience
>The BCP should define a mechanism by which a re-originating relay can publish
>its
>operational status in a domain-authoritative, machine-readable form
no-one will care ... email is just not handled that way in 2026 and I
can see no incentives for anyone to care what you self-declare.
- --
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/AwUBajNBWGHfC/FfW545EQLQzQCgrAojj2ZXhTv30p92tHJlJQ0/TrkAoP2N
zlnSVRWpTd9XNO6XPHUWWL7D
=Ypp/
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
