Subject: [dmarc-ietf] BATV

From: Douglas Foster <[email-masked]>
Date: Sat, 16 Apr 2022 08:34:28 -0400

I would like to see John Levine's BATV document revived from expired draft
status
https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv

BATV is in use within the current mail stream, and one commercial product
has cloned it to make a proprietary version of the same idea, so it is time
to declare it a success.  More importantly, it provides a general
technique, based on signature and timestamp, which permits private
communication between MTAs using insecure RFC5322 header fields.  That
technique has other uses.

For example, A-R does not include a signature security mechanism, so
implementers must be concerned about injection of spoofed A-R records.
 Because ARC is dependent on the secure transmission of A-R within one
organization, weak A-R also weakens ARC.  Both problems would have been
avoided by using the BATV signature system, but expired drafts make poor
reference documents for other RFCs

Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 16 Apr 2022 19:17:46 -0700

> technique has other uses.

Who's using it?  Which commercial product are you talking about?

I wrote and released an open source BATV filter for use with postfix and
sendmail back when it was a new idea.  The interest in the filter or in the
specification was negligible, as there were legitimate use cases with which
it interfered, such as these:

https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation#Problems

> reference documents for other RFCs

If you're following the A-R specification, you only trust your own A-R
fields (unless you really know what you're doing), and your border MTAs are
supposed to strip anything it identifies as spoofed.  In theory, you can
trust anything you see beyond that point that's bearing your own
authserv-id.  If you think that's not enough, you could DKIM sign the
message on ingress, including the A-R field you're adding on the way in, so
that it can be proven legitimate.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2022 22:30:36 -0400

It appears that Murray S. Kucherawy  <[email-masked]> said:
>-=-=-=-=-=-

I wouldn't. It was an interesting experiment but it didn't turn out to
solve useful problems, and as Murray noted, it broke a noticable
amount of legitimate mail. I still have BATV code in my MTA but it's
been turned off for years.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sun, 17 Apr 2022 16:52:39 -0400

Your DKIM solution is a viable one for the A-R problem, and would also work
for the other idea which triggered the suggestion.
.
>From an ideal standpoint, I would argue that stripping of prior A-R records
should occur at every entry point (Unauthenticated SMTP, Authenticated
SMTP, ActiveSync, EWS, MAPI).    I am not convinced that stripping is
possible from all of those sources, so A-R has always seemed vulnerable to
a persistent attacker.

To your deployment questions:    Barracuda is the commercial
implementation, but it uses "BTV1==" instead of "PRVS=".    I have logged
195 incoming MailFrom domains that are currently using one or the other
technique, including Ricoh (copiers), Cracker Barrel (restaurants), Cigna
(insurance), Experian (credit), Lilly (Pharmaceuticals), and CrowdStrike.

You are correct that it is a small percentage of mail volume; for me it is
less than 1%.  It is also worth noting that fake bounce attacks were a fad
several years ago, but have become rare.

Doug

On Sat, Apr 16, 2022 at 10:17 PM Murray S. Kucherawy <[email-masked]>
wrote:

>> I would like to see John Levine's BATV document revived from expired
>> draft status