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 "[EMAIL PROTECTED]" That way you don't risk fudging peoples callouts? I can't see any cons to this... Mike -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
