[ih] Various tests

[Matt Mathis]

inline

On Sun, Feb 11, 2024 at 8:36 AM Dave Crocker via Internet-history <
internet-history at elists.isoc.org> wrote:

> On 2/11/2024 8:10 AM, Matt Mathis via Internet-history wrote:
> > I'm under the impression that this is the problem that ARC is supposed to
> > solve.
>
> It is.  It is also complex and has had very limited uptake.
>

The Feb 1st change is pretty clearly intended to force uptake, and foster
large scale debugging.

> The email intermediary, namely the list itself, can use ARC to
> > certify that it confirmed the signatures on the earlier hops in the
> > delivery path.
>
> Besides the underlying complexity of the mechanism itself, it requires a
> new, and different, type of reputation analysis: Should statements of
> the ARC signer be believed?  And then it requires modifying the
> filtering engine to use this indirect vetting.
>
>
>
> > It's been widely published that Google and Yahoo! Started requiring DMARC
> > reports as of February 1st and that they would start statistically not
> > deliver mail from domains not using DMARC.   (Yahoo provides mail service
> > for at least 5 large ISPs)
>
> That's not quite what they said they require:  they limited the
> requirement to bulk senders.
>

However, as a small domain that is a client of Mailchimp, we seemed to be
included.   Nearly all of the pieces were there, once our hosting company
updated their DKIM credentials, and I walked through Mailchimp's procedure
to add them to our DNS.


> > It's amusing that they didn't require any specific DMARC actions, only
> that
>
> DMARC effectively provides 3 functions:
>
>  1. Validation of the From: email address domain name.  So, it is an
>     added authentication semantic, claiming a degree of validation of
>     the author's address.
>  2. A requested handling of non-validating messages
>  3. A reporting mechanism, for receivers to tell senders what they got,
>     purporting to be from the sender's domain
>
> The new operational requirement enforces function #1 on bulk senders.
> That's a pretty significant step, even without the other 2 functions.
>
> Actually the errors from google pointed to instructions for #3 - they only
required turning on reporting.   However, once I started looking at the
reports, other things got fixed, which was my point.


> > you turn on the reports; but once you have the reports, bugs and
> > configuration problems become glaringly obvious;
>
> When DMARC was being developed, my own reaction was the the reporting
> function would likely be the biggest benefit.  I haven't tracked this in
> detail, but I gather it's had some mixed results, though it probably
> does have the benefit you cite, during initial stages of using DMARC.
>

Most of my Internet career can be summed up "Exposing hidden bugs, to cause
others to fix them".   I do not have enough extertice to be able to tell
if  DKIM/SPF/ARC/DMARC have any remaining holes

>   and once you fix them
> > sammers forging email from your domain become glaringly obvious; and then
> > when you change the disposition to quarantine (request that downstream
> MTAs
> > treat signature violations as spam); the spammers go away.
>
> No they don't.  They merelystop playing the game of spoofing the From:
> field.  And that game has never been always played, when sending spam.
>
I should have said that spammers will have to stop forging addresses.
 Sender reputations and content scanning will still be needed (Furthermore
since Feb 1st, somebody created a gmail account masquerading as my wife...)


> First, note that users these days typically don't see the From: field
> email address and even when they see it it does not alter their
> susceptibility to spammy content.
>
> Second, DMARC is useful because failures correlate with spam, not
> because spam has to spoof From: field addresses.
>
> Finally, note that the From: field rewriting done by mailing lists
> demonstrates how easy it is to route around DMARC.
>

I suspect that many (most?) (all?)  fail SPF and or DKIM, but the policies
are set to none, so the messages get delivered anyhow.  Both SPF and DKIM
have the problem that they can't easily be tested and monitored at scale,
so they are dangerous to your own users to turn them on.   DMARC reporting
fixes this specific problem.


>
>
> > Unless the email wizards missed something it appears that as DMARC rolls
> > out we will have strong end-to-end cryptographic signatures of the ISP
> > which authenticated the human originating every message.
>
> It doesn't actually authenticate the author.  It authenticates the
> author's domain.  In shared environment -- statistically, that is all
> the email addresses in the world -- the semantic difference is significant.
>

Like I said, it authenticates the ISP that authenticated the human.   This
is very robust for some ISP (e.g. with other business relationships with
the customer), but not so much for free accounts provided by the likes
gmail and others.

Thanks,
--MM--
Evil is defined by mortals who think they know "The Truth" and use force to
apply it to others.
-------------------------------------------
Matt Mathis  (Email is best)
Home & mobile: 412-654-7529 please leave a message if you must call.


> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>