Re: [exim] BATV configuration

On 2008-05-30 at 15:19 -0400, Lars Nordin wrote:
> I'm somewhat of Exim newcomer so some things may be wrong - corrections or
> comments are welcome; most of this I have cobbled together from multiple
> sources on the web.

I have a comment, which applies equally to the documented method as to
yours.

I think there's a race-condition incompatibility here with greylisting
implemented by remote sites which may slightly hinder your ability to
send email in a timely manner.

I might be wrong, since I don't yet use BATV/PRVS; but I've been
thinking about how to implement it safely.

> This setup is for the newer/newest draft of BATV where the format of the
> address is: prvs=kdddhhhhhh=LOCAL_PART@DOMAIN

Here, ddd is the expiry day. This string is being calculated at
transport time. I believe that means that it's recalculated with every
delivery attempt, instead of being stored in the spool file. As a
result, if you attempt to send at 23:55 UTC and get a deferral and then
try again at 00:10 UTC (the next day from the GMT/UTC perspective) then
you will be using a new sender address, so will be greylisted again from
scratch. The next retry should be fine, provided that you retry within
23 hours and 50 minutes; there's a further risk if the remote site was
down, is now up but you've already backed off to rather lengthy delays
between attempts, but waiting longer than a day would be silly so you
*should* be okay here.

I don't know how many spam-filtering implementations score up IPs which
are greylisted and never retry (exempting the big providers using
outbound pools); having an occasionally deteriorating reputation here
wouldn't help. A good greylisting solution going forward will be one
which is BATV-aware and supports PRVS by looking past increments in the
day columns. This doesn't help people trying to be compatible with
remote sites as they exist today.

Myself, I feel that this sort of change in behaviour depending upon the
time of day is the sort of thing which just leads to problems that are
hard to spot, so should be avoided.

One way around this is to pass the new address down to the Transport in
$address_data by setting "address_data = ${prvs ...}" on the Router;
this will be stored with the email and so won't change. You then set
"return_path = $address_data" in the transport.

This method is dependent upon PRVS not being dependent upon the
recipient; if you're using a relatively static set of keys, this
shouldn't matter, but if you're looking up the key and key index from a
DB or some such and it depends upon the recipient domain, then you'll
need to set "max_rcpt = 1" on the transport.


Others will accept an occasional second sending delay and won't think
this added extra complexity worthwhile. Fair enough.

I'll note that it's 5pm here and I'm sending this less than 1 minute
after 00:00 UTC. ;-)

Regards,
-Phil