Re: [dmarc-ietf] BATV

["Murray S. Kucherawy" <[e-mail]>]

On Sat, Apr 16, 2022 at 5:35 AM Douglas Foster <
[e-mail]> wrote:

> 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.
>

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

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
>

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