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 protected]> wrote: > On Sat, Apr 16, 2022 at 5:35 AM Douglas Foster < > [email protected]> 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
