BATV-milter currently does sender/recipient rewriting
at End Of Message.
The problem with postponing the re-write is that sender verification schemes that perform a SMTP connect back and attempt to validate a BATV-signed mail ... but no body fail.
msn/hotmail do this, as do some mailing lists
For the sanity of other milters (so they see the proper address, not the BATV form), and these SMTP callbacks, it would seem that actually changing recipients in the
mlfi_envrcpt routine would be best
And, by also moving the sender transformations down, batv becomes totally transparent to the local MTA - any following rulesets, milters, checkcompat(), etc. will only see the proper - unmunged
sender/recipient
Which, I think, argues for changing the X-Header from an append to an insert - to help diagnose improper placement of the milter
Modifying the X-BATV: header to be prepended rather than appended is easy. It'll be done in the next release.
It's not currently possible to have the filter issue its recipient changes prior to end-of-message because that's the only phase of communication in which those requests from the filter are allowed.
However, I'm not sure it matters. I believe what's going on is that your MTA is validating the BATV-signed userid before it even tells the filter what was attempted. You might just need to tell the MTA to skip that step so that batv-filter gets a chance to process the recipient.
Sorry for the red-herring wrt time of update - it all made sense in my own mad little world...
I'll look at where-else (mimedefang, etc.) will be needing to strip prvs=.*= off
The addresses are indeed being validated due being seen as local-delivery - so removing the w flag would
be the only way around the premature rejection (unless I'm missing something).
Is BATV not meant to be run a MTA that does local delivery - or is it relegated to border-MTAs - or, am I just being dense (wouldn't be the first, nor the last time)