Chris Meadors wrote:
>>> Is my understanding correct? If so, what is the amount of time until
>>> expiry? I can't see anywhere to configure this so I'm guessing I've
>>> either misunderstood how it works, or the value is hardcoded and
>>> unchangable?
>> Ok. I dug through expand.c and found what looked like the right place.
>> Seems to be hardcoded to 7 days. I just skipped my system date forward 6
>> days and 8 days respectively to test this, and it is confirmed.
> That's where I found it too, and the same number I discovered.
Sounds like the docs need updating in that case. I'll make a note to
come up with some text when I get a few minutes if no one gets there first.
>> I think this information belongs in the documentation somewhere?
>>
>>> Also, in the examples I've seen in the documentation and on the wiki
>>> there are different, "secrets", for each sender address. Is that
>>> necessary? I don't see the logic behind it...
>> I'd still like an answer on this one if possible?
> I always thought that the example in the spec.txt was over-kill.
> Something that would be deployed on a server that allowed each user to
> individually enable BATV for their self, and select their own hash key.
>
> I just went with a single macro defined secret in my conf and enabled
> BATV for one entire domain.
>
> I suppose having the same one-way hash performed for all users could
> possible provide more information to someone wanting to forge your BATV
> return-path. But what would that gain them? The ability to send your
> users bounces? BATV is not externally verifiable so forging it does not
> allow someone to impersonate your server to anyone but your own server.
> That coupled with the time it would take to brute force the secret from
> the hash (even with multiple samples) really makes it seem pretty safe
> to use the same secret domain-wide.
I agree with all of the above. The example at
http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECTverifyPRVS
and on the wiki doesn't need the added complexity of having an SQL
lookup to retrieve the secret. It only adds confusion imho.
Another issue that I forgot to bring up. If you do batv verification in
the rcpt acl, you're going to end up preventing other systems from doing
callouts in certain circumstances. I agree these will be rare, but would
it be better to do the following:
1.) In the rcpt acl defer each recipient after the first if the sender
is null.
2.) Do the batv validation in the pre-data acl using "$recipients"
instead of "$local_part@$domain"
That way you don't risk fudging peoples callouts? I can't see any cons
to this...
Mike
