I use source generically, to represent the identifiers which correctly represent the malicious or trusted entity. The particulars depend on the boundaries between the message originator and the independent infrastructure which it may be using.
For malicious impersonation, I consider these possibilities: - If MailFrom is verified by SPF or presumed true, the blocked source is the MailFrom domain or full address - If MailFrom is unverifiable and presumed false, the blocked source is the server or server farm. At minimum, the Source IP deserves a block. But if either the HELO or Reverse DNS are believed to correctly indicate a malicious server organization, then I block on the server domain name as well. Forward-confirmed DNS is useful for confirming that the host name reflects the server organization. For overrides, the logic is similar: Often, the problem is an email service provider (ESP) that does not apply a signature. - For well-known ESPs like ConstantContact and SendGrid, I trust their business practices to prevent impersonation between clients. So my rule says that if the MailFrom domain name is ConstantContact.com and it is verified by SPF, then the From address is presumed to be legitimate. (This is an assertion that identities are correct; some identities will still be malicious and deserve a block.) - For less recognized ESPs, I inspect the message to determine if it is acceptable, and then add a more limited rule that says the From is acceptably verified if the MailFrom domain is a specific value, MailFrom is verified by SPF and the From domain is a specific trusted value. Either approach can be used to solves the previously-discussed problem of a Girl Scout group which uses a Yahoo address to send a newsletter from Constant Contact. This type of rule can also be used to say that all messages from a content-altering mailing list are exempt from DMARC enforcement when the MailFrom address is a known list address (or trusted domain name), and the MailFrom address is verified by SPF. This rule would be appropriate if the mailing list actually takes measures to verify that the asserted From address is verifiable when received by the list. If the list cannot ensure that posts actually come from list members, then trust is not really an option. My key points: - If the evaluator wants optimal disposition decisions based on Sender Authentication, the evaluator needs to contribute to the solution. This is entirely consistent with actions that evaluators should be taking to ensure that content filtering produces optimal results. - The actions that an evaluator can take are determined by the capabilities of his email filtering product. As I have tried to outline above, those capabilities are amenable to definition in our document, if we accept the idea that a complete protocol addresses both normal operation and error recovery. Doug Foster On Fri, Jan 27, 2023 at 3:23 PM Jim Fenton <[email protected]> wrote: > On 25 Jan 2023, at 3:57, Douglas Foster wrote: > > > We know of two current responses to DMARC Damage: (1) Many senders > > avoid p=REJECT, so that damage-prone evaluators cannot learn anything > > useful from DMARC evaluation, and (2) sophisticated evaluators throw > DMARC > > results into a proprietary mix with hundreds of other data points to > > develop a disposition decision that is only loosely related to domain > owner > > policy. Both of these responses indicate that our protocol, as written, > > does not meet the needs of either senders or evaluators. > > Or (3) evaluators ignore DMARC. > > > A result of "DMARC Fail" raises the possibility that a message is from a > > malicious source. This is an important question, but it only needs to > be > > answered once. If a source is malicious, all messages from the source > > need to be blocked. If a source is determined to not be malicious, the > > source needs to be fingerprinted so that future messages from that source > > are handled as acceptably identified. The question can be answered with > > either manual effort or sophisticated analysis and artificial > intelligence, > > but once it is answered the evaluator can be protected from malicious > > messages while recipients are protected from damaged mail. > > I’m probably missing some context here, but I’m not clear on what a source > is in this context. A specific email address, a specific sending MTA, or a > domain? > > -Jim >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
