Re: [dmarc-ietf] DMARC and ARC

[Douglas Foster <[e-mail]>]

Thanks for engaging Murray.

On the usefulness of source blacklisting:

I have been using the model I described for about a year.    I have two
categories of mailers that account for nearly all of my spam:
 spamer-owned infrastructure which sends direct, and email service
providers that accept all customers, including criminals.   ESP messages
will arrive SPF-aligned with the ESP domain, the From address indicates the
client, and DKIM signing is used when necessary for DMARC compliance.

I don't think I have seen any problems with infected servers or even
infected accounts from trusted sources, which is surprising.   Compliments
to GMail that the worst that I get from them is unwanted-but-persistent
advertising.

Our employee base is measured in 4 digits, not 6, so our volume is smaller
than many, and my desired-sender list is correspondingly small.   That has
meant that I have not had false positives with blacklisting.

When a confirmed spam is received from spam infrastructure, the best
defense is to blacklist the IP, the host domain, and the address domains
(unless one of these has been spoofed.)    In practice, this is tedious to
do consistently.   Blocking on server domain has proved pretty effective.
 When blocking on IP, we often block a subnet.   Depending how quickly we
identify the spam source, the message history sometimes provides a good
outline of the boundaries of the spam infrastructure.   Bottom line:
 spammer domains do change frequently, and spammers often have a bunch of
servers.  But their servers do not actually change very much.   Obviously,
this means I have not yet been attacked by a thousand-member bot-net.

For spam received from ESPs, blocking on the From address works, because
the ESP does verify the client identity and does not allow clients to spoof
each other.   They just don't vet client integrity.    So I classify
messages arriving from the ESP into known-bad=block, known-good=allow, and
unknown=quarantine.   Forwarded messages will typically rewrite the SMTP
domain for SPF compliance.   This means that I no longer know that the
unclassified From address is from the untrusted ESP and therefore needs to
be quarantined.    DMARC is a great solution for authorizing ESPs to send
direct messages on behalf of a domain, because SPF did not work well for
those messages.   It is not a perfect solution for forwarded mail because
even unmodified messages are subjected to data loss during forwarding.

On Accountability:

A message from A to B to C to Gmail does not mean that Gmail has a
relationship with A.    Gmail is acting as your agent, and it does a pretty
good job of protecting you.    A to B to C do have a relationship with each
other, or one of them would have been bypassed.    For legitimate senders,
I expect that the organizational hops will be at most two:    the source
domain, and the outbound email filtering service used by the source domain.

Mailing lists should be the cleanest traffic on the internet, because it
should be a small matter for the list to verify sources and minimize risk
by rejecting even slightly-doubtful messages.    Yet we have had exchanges
about how mailing list do not want to sign messages because they think
it will make them accountable for what they forward.   They are accountable
for what they forward, with or without DKIM.

Auto-forwarding operations are much more problematic because they have
strong incentives to minimize false positives.   They are still
accountable, but they will be perceived by recipient as unreliable - the
same way that I handle my problem ESPs.

New vs Existing messages:

For these purposes, mailing list output is only a new message if the
mailing list is the only party responsible for its content.  I am focused
on identifying malicious and unwanted message sources, and the mailing list
is asserting that it is not the originating source.

DF

--


On Mon, Dec 7, 2020 at 12:15 AM Murray S. Kucherawy <[e-mail]>
wrote:

> On Fri, Dec 4, 2020 at 7:58 PM Douglas Foster <
> [e-mail]> wrote:
>
>> First, lets begin with the obvious:   malicious messages come from
>> enterprises that are in the malicious message business.   They rarely send
>> just one message, and their content changes continually.   Therefore, my
>> priority is to block malicious sources.   Messages that are correctly
>> blocked on content, rather than source, are the canary-in-the-mine which
>> warns me that my sender blocks need to be tightened.
>>
>
> I was under the impression from my work in the anti-spam world that
> sources also change.  It's trivial to come from a new IP address or sign
> with a new domain name when I think you're blocking me.  Thus, negative
> reputations are generally not useful to accumulate long term.  On the
> contrary, the thing that's mostly reliable is static sources that have good
> reputations, because they tend to remain (mostly) static, and they work to
> preserve their reputations.  I tend to give them preferential treatment.
>
> If a message is not forwarded, every organization involved in its delivery
>> is assumed to have a relationship to the sender and therefore a shared
>> responsibility for the final product.   DMARC, SPF, and many spam filters
>> assume that the adjacent MTA is the only source that needs to be evaluated.
>>
> This seems overly general.  A message going from A to B to C to me here at
> Gmail means Gmail has a relationship with A?
>
> Forwarding introduces an intermediary organization which presumably
>> operates on behalf of the recipient, rather than the sender.   It is not
>> involved in the creation of the message and has no economic relationship
>> with most of the message sources.   More importantly, because it will be
>> forwarding messages from sources with a variety of reputations, the
>> forwarder will be perceived as having a very unreliable reputation –
>> sending both very much unwanted content and very much wanted content from
>> the same or overlapping identifiers.   SPF and DMARC force the forwarder to
>> reliably identify itself, but in this process, they force the forwarder to
>> hide information that the receiving MTA needs for proper message
>> filtering.  This aggravates any effort to filter based on original-source
>> identity.
>>
> I'm also confused here, because it's ambiguous what you mean by
> Forwarder.  Some forwarders simply replace the envelope and send the
> message on its way with no body modifications and only trace header field
> changes.  They don't meet the definition you're describing because no
> details are hidden.  Others, like MLMs, may mutate the message and re-post
> it, but I would argue that's not forwarding, that's a new message; the list
> is the originator.
>
> -MSK
>