About your proposal to encourage silent discard: I'm sorry that we have not provided any feedback. Feeling ignored or shunned by the group is worse than having an idea rejected. For my part, I am a skeptic of your proposal.
The best outcome would be for the evaluator to perform all operations before releasing the SMTP session, so that rejection can be handled with an SMTP result code and extended status code, rather than with a non-delivery report. The RFC provides for sessions to remain open a long time so that this can be done. If I remember correctly, the rule is 5 minutes to evaluate MAIL FROM and 10 minutes to evaluate END OF DATA. I suppose that many sending systems ignore this rule and timeout more quickly, so really long evaluation processes run the risk of communication breakdowns. Nonetheless, if the evaluation can be completed in one step, you do not have the flood of non-delivery reports which cause your concern. Unfortunately, a lot of email configurations use a pipeline process which makes this behavior difficult to achieve. I am actually surprised that you have a problem with too many NDRs. When I judge a message source to be unwanted or a threat, I don't want to help them, so I don't currently send NDRs. Sometimes that is a problem, because an important correspondent does not realize that an email address was typed incorrectly so his message was discarded. But notifying malicious senders about invalid addresses helps them to do address harvesting. For those that do send NDRs, the point of the message is to help both of you. If your mailing list message is being blocked because it fails DMARC, you should do From-rewriting or drop the recipient to fix the problem. If I don't want your messages for other reasons, my preferred outcome is for you to stop sending me unwanted messages. If your message is wanted but is being blocked because of a problem that you can fix, my preferred outcome is for you to fix the problem on your end, so that I don't have to fix the problem on my end. You will need an extended status code to have any hope of knowing what problem to fix on your end. So it becomes important for the NDR to include an extended status code. I realize that parsing an NDR to obtain useful information is difficult. I won't be at the meeting. Doug Foster On Fri, Nov 5, 2021 at 11:28 AM Baptiste Carvello < de...@baptiste-carvello.net> wrote: > Hi, > > > (Direct link to the agenda: > > https://datatracker.ietf.org/meeting/112/materials/agenda-112-dmarc ) > > > > DMARC working group IETF 112 agenda > > > > 3. Bring discussion of indirect email flows to a close. > > Tracking tickets 79, 92, 94, 100, and 122 > > We will get to this topic if there's time, but the policy discovery > discussion has priority. > > if you get to this, and before "closing" this discussion, please > consider the following proposals: > > 1. (already proposed, but I received no feedback): encourage DMARC > evaluators to make sure no bounce is generated for REJECT when the > message appears to come from a mailing list (silently discarding instead). > > Bounces coming in by the thousands are no feedback, but sheer > aggression. The threat of this aggression allows some DMARC implementers > to rely on the mailing list operators to implement workarounds forever > (as Ale among others likes to argue). Which makes bootstrapping any new > solution difficult. > > 2. (this proposal is new): complement ARC with a secondary DKIM > signature on the first hop. > > Under this proposal, a DMARC-implementing domain who wants their > outgoing mail to be possibly involved in indirect mailflow (most senders > do) would appose on each outgoing message a secondary DKIM signature > signing the following headers: the recipient address, in a normalized > form (here, for example: "To: dmarc@ietf.org"), From, Date and Message-ID. > > Thus the evaluator could make sure that the ARC signing domain has some > relationship with the sender: namely that the sender sent a recent > direct message to this intermediary. This in itself doesn't prove that > the intermediary is trustworthy, but should make the life of fraudsters > sufficiently difficult to deter them in most cases (they would need to > first obtain a genuine message from whoever they try to impersonate). > > Cheers, > Baptiste > > _______________________________________________ > 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
