Re: [dmarc-ietf] DMARC as an instance of a class
On 7/3/2020 10:34 AM, ned+dm...@mrochek.com wrote: On 7/3/2020 9:58 AM, Hector Santos wrote: 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. 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 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as an instance of a class
On 7/3/2020 9:58 AM, Hector Santos wrote: > On 7/1/2020 7:51 PM, John Levine wrote: >> >> ##, ###. Spam filters like spamassassin have looked at the headers >> along with everything else in the message forever. > > 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. Good to know I'm not the only one who confuses those. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as an instance of a class
On 7/3/2020 9:58 AM, Hector Santos wrote: On 7/1/2020 7:51 PM, John Levine wrote: ##, ###. Spam filters like spamassassin have looked at the headers along with everything else in the message forever. 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. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC as an instance of a class
On 7/1/2020 7:51 PM, John Levine wrote:
In article 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.
##, ###. Spam filters like spamassassin have looked at the headers
along with everything else in the message forever.
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.
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.
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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC as an instance of a class
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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
