Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles

Sam Varshavchik <mrsam@courier-mta.com> Tue, 25 May 2021 21:55 UTC

Return-Path: <mrsam@courier-mta.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E703A0DA0 for <ietf-smtp@ietfa.amsl.com>; Tue, 25 May 2021 14:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_PBL=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3GQX7UpPYO3 for <ietf-smtp@ietfa.amsl.com>; Tue, 25 May 2021 14:55:07 -0700 (PDT)
Received: from mailx.courier-mta.com (mailx.courier-mta.com [68.166.206.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A3E3A0D9A for <ietf-smtp@ietf.org>; Tue, 25 May 2021 14:55:07 -0700 (PDT)
Received: from monster.email-scan.com (monster.email-scan.com [::ffff:192.168.0.2]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by www.courier-mta.com with UTF8SMTPS id 000000000030000A.0000000060AD7233.0000845D; Tue, 25 May 2021 17:54:59 -0400
Received: from monster.email-scan.com (localhost [127.0.0.1]) (IDENT: uid 1004) by monster.email-scan.com with UTF8SMTP id 0000000000020394.0000000060AD7233.00013CF7; Tue, 25 May 2021 17:54:59 -0400
References: <20210525184303.573878B888E@ary.qy>
Message-ID: <cone.1621979698.997254.77709.1004@monster.email-scan.com>
X-Mailer: http://www.courier-mta.org/cone/
From: Sam Varshavchik <mrsam@courier-mta.com>
To: ietf-smtp@ietf.org
Date: Tue, 25 May 2021 17:54:58 -0400
Mime-Version: 1.0
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg
Content-Type: multipart/signed; boundary="=_monster.email-scan.com-77709-1621979699-0001"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/0-X8EmNi-8ZC7QsSCbUn-d6hE7c>
Subject: Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2021 21:55:12 -0000

John Levine writes:

> It appears that Sam Varshavchik  <mrsam@courier-mta.com> said:
> >I should clarify this. I see that occasionally. But when it does, I seem to
> >always end up moving my goalposts, and conclude that the mail provider
> >itself is rogue, and made a business decision to go into the business of
> >providing spam outsourcing services, with some non-spam mail services on the
> >side. So I treat it as a bad mail source.
>
> You and I do not run large mail systems.  The bigger you are, the less  
> latitude
> you have to punish senders (even places like Sendgrid that deserve it) if it
> means also losing the real mail they send.  On my small system I have  
> elaborate
> rules to post-filter Sendgrid's mail because there is useful stuff in with  
> the crud
> and my users are sad if it disappears.

And that's why Sendgrid – and everyone else in their position – has no  
incentive to clean up their act. Why should they, when most recipients on  
the other side of the earth are willing to expend their effort to accomodate  
Sendgrid – or anyone else in their position?

It used to be that they would just segregate their dirty mail from their  
clean mail on different IP addresses, and that was their preferred solution:  
go ahead, feel free to just block those guys over there, they'll continue to  
pay us anyway.

Now, they don't even have to do that. They can simply say: hey, here's the  
sender, feel free to sort the senders yourself. The burden on you to go  
through the hassle of identifying the sender, and filtering them out.

I think what's happening, in the grand scheme of things, is the elimination  
of small to medium E-mail providers. E-mail is being split between the  
extreme low end: individuals running their own E-mail for either themselves  
or their organization. They don't realy on E-mail, don't consider it  
critical, and can afford to brutally filter their incoming E-mail. They  
don't mind an occasional loss of an attempted personal contact from the  
public. They just want to avoid having their mailbox getting filled with  
junk every day.

And then we have the large E-mail providers. They can afford to invest  
resources in implementing sophisticated, score-based mail filtering  
techniques, employing DKIM, DMARC, and paying for a non-free blacklist.

A small-to-medium E-mail provider just won't have the resources to compete,  
I believe, over the long term. What we're talking about here, will /not/ be  
sufficient to clean their incoming E-mail, by itself. They'll still have to  
constantly waste time constantly adjusting their filters and figure out what  
to do with each new source of mail they haven't seen before.

> >Eh, no. A large majority of user-facing mail clients are now hiding the
> >sending mail address, and showing only the name, up front.
> >
> >From: "Paypal Customer Service" <kjsdfjklk@934iowero.us>
>
> Yeah, we know.  But large providers tell me that DMARC still blocks a great
> deal of phish that uses the target's actual domain name.

So does SPF, actually.

May 25 07:10:29 shorty courieresmtpd[28905]: error,relay=::ffff: 
185.222.57.81,port=56202,from=<admin@courier-mta.com>: 517 SPF fail courier- 
mta.com: Address does not pass the Sender Policy Framework
May 25 07:50:58 shorty courieresmtpd[29001]: error,relay=::ffff: 
195.140.213.254,port=54000,from=<raviadappa@bflhydro.com>: 517 SPF fail  
bflhydro.com: Address does not pass the Sender Policy Framework
May 25 08:57:31 shorty courieresmtpd[29918]: error,relay=::ffff: 
36.92.9.83,port=7329,from=<info@lee.org>: 517 SPF fail info@lee.org: Address  
does not pass the Sender Policy Framework

SPF is heck of a lot easier to implement.

And, thinking about this more: if something will fail a DMARC check, it's  
almost a certainty that it'll fail an SPF check too. Chances are very good  
that a domain that uses DMARC will also have an SPF record.

> >Most people will see "Paypal Customer Service". Valid domain signature for
> >934iowero.us, and straight it goes into your Inbox.
>
> You're making the same mistake again.  DMARC is not a whitelist.  If

I didn't say that it was.

> something is
> DMARC aligned, all that means is that it was really sent by the domain in  
> the From:
> header.

Right, but my point was DMARC will verify 934iowero.us, and the recipient  
sees that the mail is from "Paypal Customer Service".

And if 934iowero.us is a brand new domain, with no reputation, then what?

>        You still apply reputaiton and other spam filters to it.  It's not  
> a FUSSP.

And if it's a brand new domain and has no reputation?

So, what's the starting point here. What are we going to do with new domains  
that validate in DMARC/DKIM, but have no reputation.

A) Vote them down. This winds up with large E-mail providers keeping  
everyone off their turf. You have poor deliverability with a new domain,  
unless you pay the danegold to big E-mail providers to send from their  
infrastructure.

B) Do not vote them down. Factor in bad reputation only. Do not mark down in  
absence of no reputation. This winds up with cheap domain recycling. Spam  
the crap out of everyone using a new domain, until its reputation sinks.  
Then switch to the next throwaway domain.

My point is: the domain-based reputation approach is being pushed by large  
email providers because they don't want to terminate their paying customers,  
who are paying them for the privilege of sending spam. These large email  
providers would much rather prefer to do nothing more than an absolute  
minimum amount of work to merely identify who is sending mail from them.  
Then they can wash their hands, proclaim that their job is done; and it is  
up to you to block their spambags, if you wish. You do all the work of  
figuring out each domain's reputation.

Now, in that scenario, I'll agree, domain authentication would be very  
useful for them. But only for them, and nobody else, except for those that  
are willing to expend their own resources to filter the spam sources that  
they should not have to filter in the first place.

And as long as this situation is acceptable by everyone, I don't see the  
situation changing, since the situation is acceptable to everyone.