Getting back on the horse after time away... I propose the following text to address Eliot's concerns (and I include the preceding paragraph as context):
As discussed in "Interoperability Issues between DMARC and Indirect Email Flows" [@!RFC7960], use of p=reject can be incompatible with and cause interoperability problems to indirect message flows such as "alumni forwarders", role-based email aliases, and mailing lists across the Internet. As an example of this, a bank might send only targeted messages to account holders. Those account holders might have given their bank addresses such as [email protected] (an address that relays the messages to another address with a real mailbox) or [email protected] (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will necessarily fail SPF checks, as the incoming IP address will be that of example.edu or association.example, and not an address authorized for the sending domain. DKIM signatures will generally remain valid in these relay situations. On Tue, Aug 27, 2024 at 5:54 AM Eliot Lear <[email protected]> wrote: > Hi Barry, > > I just noticed something editorial in nature in the following paragraph in > Section 7.5: > > A domain that expects to send only targeted messages to account holders - > a bank, for example - could have account holders using addresses such as > [email protected] (an address that relays the messages to another > address with a real mailbox) or [email protected] (a role-based > address that does similar relaying for the current head of finance at the > association). When such mail is delivered to the actual recipient > mailbox... > > That first sentence is long and difficult to parse; and domains don't have > expectations. I suggest the following alternative in line with existing > practice and intent: > > Some senders use email addresses from domains that are not associated with > a particular SMTP server. For example, Robin Jones might send messages as > [email protected] when in reality that person's mail flows through > some other bigmailserver.example.com. Another example would be someone > who sends from a role-based address such as > [email protected]. When such mail is > delivered to the actual recipient mailbox... > > {yes, I changed the examples. Change them back if you like} > > This is intended strictly (so to speak) as a friendly amendment. If > anyone has concerns, I've seen worse writing (from myself, I might add), > and we should just move on. > > Eliot > On 08.08.2024 20:58, Barry Leiba wrote: > > I've asked the document shepherd (Tim Wicinski, and thanks for > volunteering to handle this!) to do his final review and get the > writeup done, and I've alerted Murray that it's coming soon. I hope > those next steps will happen very soon. > > Barry, as chair > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Todd Herr | Technical Director, Standards & Ecosystem Email: [email protected] Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
