Hello, when a message is wrongly evalutated as spam, and is left therefore unnoticed, it is nobody’s fault. You can signal the users as you want, including the users, which just redirect mails on your host, and do not utilize the “Spam” store there.
A message is either likely spam (subject to signaling), or it is not likely spam. When the message is likely spam, you can signal the sender by sending a non delivery report. That report can contain information, entered by the intended recipient, like snail mail address or phone number. If you signal the sender (by rejecting at SMTP level) you do not need a signaling method on the recipients’ side, that works across all MUAs. Besides, there is no “nobody is fault for the overseen signaled message”. If you run a server with 10 local users and 10 000 redirecting addresses (aliases), you have to use a signaling method, that does not break the DKIM-signature, and works for redirected emails. For users that utilize just redirecting there is no “neither likely spam, nor unlikely spam” category. And the other users also do not need such category. Greetings Дилян On Sun, 2020-06-07 at 23:04 +0000, Douglas E. Foster wrote: > I am trying to play by the rules and not chase topics outside the one > assigned, but since several have jumped on my comment, I will follow > up briefly. > > Dave Crocker wrote > Since there has been a demonstrated lack of efficacy in this sort of > display, there needs to be an objective basis for knowing that any > new such requirement will be useful. > > Every email filtering product that I have examined has provided a > user-signaling system, using one or more of the following: > * tagging the subject, > * adding text as a body header or body footer > * converting the suspect message into an attachment of a > replacement message, > * soft-quarantining, where the user has unrestricted control to > release the message from quarantine. > Given that market reality, I conclude that most vendors and their > customers believe that user-signalling is useful. The signalling > system does not have to prevent every mistake for the signal to be > useful. > > The problem with all current notification methods is that they are > relatively primitive, often communicating nothing substantive about > the suspicious message characteristics. They also work against other > security mechanisms. > * Any form of tagging breaks DKIM signatures, reducing the > credibility of the message if it is auto-forwarded for any reason. > > * The tagging also becomes tattooed to the message and its replies, > rather than being restricted to the trust domain that assigned the > tag. One example should suffice: a message was tagged with [SPAM?] > because the sender had an error in his SPF record and I was trying to > enforce SPF. Then when my staff replied, the originator treated the > reply as spam because the word SPAM was still in the subject line > when he received it! > We need a user notification mechanism that is local to the trust > domain and does not break DKIM signatures. You have already done the > heavy lifting for this interoperability problem with Authentication- > Results and ARC I am not expecting a "Standard" that requires every > implementation to notify every user in the same way. I am looking > for a guidance document that helps vendors to deliver products which > permit an organization to implement a notification policy which they > find to be effective and appropriate. IETF is the right > organization to take this on because the email filter, the mail > system, and the multiple MUAs are almost always a multi-vendor > configuration. > > df > > > > > _______________________________________________ > 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
