Subject: [dmarc-ietf] DMARC as an instance of a class

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 01 Jul 2020 11:34:45 GMT

DMARC either introduced or popularized the concept of filtering on the Message From.   Low-end gateways that lack DMARC support will typically do nothing with the Message From -- the header value does not appear in the message logs and it cannot be used for filtering because it is not examined.

Now that the concept has been established, spam defenses based on From filtering are a class, of which DMARC is only an instance.    Recipient systems might choose to:
Enforce DMARC on a domain even if the domain has a DMARC policy with p=none or pct=0.Enforce DMARC-equivalent requirements on a domain that has no DMARC policy at all.Block based on the TLD of the From addressBlock based on Domain reputation lookups using the From address.
This creates a difficult problem for the MLM which wants to use author as the From address.   The recipient gateway does not know the universe of all mailing list subscribers, and the list changes over time as members subscribe and unsubscribe.   The MLM does not know the universe of all domains blocked by the recipient gateway, and the list of blocked domains will change over time as policies are modified.   

These limitations of knowledge will limit our options for solutions.   I see four possible recipient configurations with specific implications for what the MLM can do.

1. Recipient system does not block based on From address
MLM options are unrestricted
2. Recipient system whitelists mailing list messages based on source server identity
MLM server must be reliably identifiable, typically using forward-confirmed DNS name.  From address is unrestricted.
3. Recipient system whitelists mailing list messages based on list identity
MLM list id must be reliably identifiable, probably using a SPF lookup on the List-ID or a DKIM signature with identifier specified to the list rather than the domain.  From address is unrestricted.
4. Recipient system blocks on From address but is unwilling to whitelist (or not yet configured to do so)
MLM needs to use its own Domain for the From address and for a verifiable DKIM signature.   Alternatively, IETF would need to provide a way to trick the recipient into accepting the message in violation of its configured policy, which it should not do.

More complicated solutions, like dual signatures, are alternatives for the middle of the above list, but are not needed for the first configuration and are excluded from the last configuration because of the "not configured" assumption.

Filtering on From Address is itself an instance of a larger class: defenses based on verified identifiers.
An identifier is useful to the spammer if the identifier might case the incoming gateway to allow a message that would otherwise be blocked.An identifier is useful to the spammer if it will be displayed to the user by the MUA, because then it can be used to perfect the spammer's social engineering attacks.
Because of these risks, SPF validation restricts unauthorized use of the RFC 5321 Mail From, and DMARC validation limits the use of the RFC 5322 Message From.   Going forward, we need to look for ways to validate any identifier that is used for either message filtering or message display.  If we do not, we should expect that some non-IETF source will do so instead.

For the current issue, changing the roles of the Sender and From fields will not be a long term solution unless the change includes validation of both fields.  The change by itself will attract spammers to whatever field remains unvalidated.

DF

---

From: "John Levine" <[email-masked]>
Date: 1 Jul 2020 19:51:27 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>DMARC either introduced or popularized the concept of filtering on the Message From.   Low-end gateways
>that lack DMARC support will typically do nothing with the Message From -- the header value does not
>appear in the message logs and it cannot be used for filtering because it is not examined.

Oh, please. Spam filters like spamassassin have looked at the headers
along with everything else in the message forever.

Given that the basis of your argument isn't true, I don't see any need
to go point by point through the rest of it.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Jul 2020 09:58:23 -0400

On 7/1/2020 7:51 PM, John Levine wrote:
> ##, #######. Spam filters like spamassassin have looked at the headers

SA is a tool that reads the entire RS232 payload.

I believe the OP was describing situations where the parameters for a 
DKIM assessor like DMARC may not always be provided in a log file or 
something that can process by their own tools.  It would be akin to 
lacking certain data bits in the AUTH-RES header for an assessor only 
looking for the header.

Accumulating these for some current or future evaluator to can explore 
is useful.  In fact, the OP actually gave me an idea to do more in the 
area, for example, log the SMTP/DKIM Identities, in a CSV file:

{timestamp},{smtp.ip},{smtp.ehlo},{smtp.mail},{smtp.to},{mail.from},{dkim.signer},{mail.sender},{list.id}, 
{reply.code}

That would be something that can imported into a SQL table or a 
spreadsheet.  But for something the sysop or 3rd party developer may 
be already reading, adding the identities not already logged to a 
process session log file, i.e. wcSMTP-{date}.log could be useful to 
them. In this case, the OP is highlighting his system is not logging 
the 5322.From in the log file.  Not a protocol item, maybe an 
implementation suggestion side note item.

All this would be something SA is not compatible with.

> to go point by point through the rest of it.

This is about synergism, like the above. A comment you may not agree 
with can be something that sparks something else.  Most folks, if not 
all, cherry pick comments to follow up on so I would appreciate it if 
WG participation is not stifled with such rude comments.  I would hope 
and expect the WG chairs and AD would be addressing this.

Have a safe holiday weekend.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Jul 2020 10:02:28 -0400

> SA is a tool that reads the entire RS232 payload.

HA! RS232 on my mind, helping an enterprise customer with his 32 modem 
server setup. Of course, I meant RFC5322.

---

From: [email-masked]
Date: Fri, 03 Jul 2020 07:34:01 -0700 (PDT)

> server setup. Of course, I meant RFC5322.

Good to know I'm not the only one who confuses those.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Jul 2020 11:33:06 -0400

> Good to know I'm not the only one who confuses those.

A good example of the mental "Query Theory" [1] lookup misdirection :-)

Be safe.

[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1959766