Re: reject_unverified_recipient and /ect/aliases delay/issue

[Wietse Venema]

Wietse:
> Perhaps use the configurable features to control caching of 'negative'
> results:
>
> address_verify_negative_cache = yes
> address_verify_negative_expire_time = 3d
> address_verify_negative_refresh_time = 3h
>
> The 'negative' results are cached to avoid overloading the server
> with address verify messages.
>
> I guess that some people can wait for 5 minutes until the negative
> cache result has expired?

Stefan Bauer:
> 5 Minutes are no problem. The default values indicate 3 hours right?

Indeed. It's a trade-off between safety and instant gratification.

Wietse

Re: reject_unverified_recipient and /ect/aliases delay/issue

[Stefan Bauer]

5 Minutes are no problem. The default values indicate 3 hours right?

   *address_verify_negative_refresh_time

(3h)*
  The  time  after which a failed address verification probe needs
  to be refreshed.


Am Fr., 14. Sep. 2018 um 20:25 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:

> Stefan Bauer:
> > Am Freitag, 14. September 2018 schrieb Wietse Venema :
> > > Stefan Bauer:
> > >> verify_cache.db seems to get corrupted or at least not updated
> properly
> > as
> > >> new/updated entries do not get correctly verified and postfix logs:
> > >>
> > >> close database /var/lib/postfix/verify_cache.db: No such file or
> > directory
> > >> > (possible Berkeley DB bug
> > >
> > > That is logged after 'postfix reload", and until now has not been
> > > a problem.  The warnming is logged just to be sure, because people
> > > keep imprving Berkeley DB.
> > >
> > >> only a postfix stop, rm verify_cache* , postfix start helps.
> > >
> > > That is complete and utter overkill.
> >
> > so what else is recommended to update the db to have recent data?
>
> Perhaps use the configurable features to control caching of 'negative'
> results:
>
> address_verify_negative_cache = yes
> address_verify_negative_expire_time = 3d
> address_verify_negative_refresh_time = 3h
>
> The 'negative' results are cached to avoid overloading the server
> with address verify messages.
>
> I guess that some people can wait for 5 minutes until the negative
> cache result has expired?
>
> Wietse
>

Re: reject_unverified_recipient and /ect/aliases delay/issue

[Wietse Venema]

Wietse Venema:
> Stefan Bauer:
> > Am Freitag, 14. September 2018 schrieb Wietse Venema :
> > > Stefan Bauer:
> > >> verify_cache.db seems to get corrupted or at least not updated properly
> > as
> > >> new/updated entries do not get correctly verified and postfix logs:
> > >>
> > >> close database /var/lib/postfix/verify_cache.db: No such file or
> > directory
> > >> > (possible Berkeley DB bug
> > >
> > > That is logged after 'postfix reload", and until now has not been
> > > a problem.  The warnming is logged just to be sure, because people
> > > keep imprving Berkeley DB.
> > >
> > >> only a postfix stop, rm verify_cache* , postfix start helps.
> > >
> > > That is complete and utter overkill.
> > 
> > so what else is recommended to update the db to have recent data?
> 
> Perhaps use the configurable features to control caching of 'negative'
> results:
> 
> address_verify_negative_cache = yes
> address_verify_negative_expire_time = 3d
> address_verify_negative_refresh_time = 3h
> 
> The 'negative' results are cached to avoid overloading the server
> with address verify messages.
> 
> I guess that some people can wait for 5 minutes until the negative
> cache result has expired?

Note that there is a subtle difference between _expire_time and
_refresh_time. The verify daemon will return the cached result, and
if a refresh is needed, it will request new address verify probe
for the email address. The probe completes in the background, and
will at some time later overwrite the cached negative result.

Wietse

Re: reject_unverified_recipient and /ect/aliases delay/issue

[Wietse Venema]

Stefan Bauer:
> Am Freitag, 14. September 2018 schrieb Wietse Venema :
> > Stefan Bauer:
> >> verify_cache.db seems to get corrupted or at least not updated properly
> as
> >> new/updated entries do not get correctly verified and postfix logs:
> >>
> >> close database /var/lib/postfix/verify_cache.db: No such file or
> directory
> >> > (possible Berkeley DB bug
> >
> > That is logged after 'postfix reload", and until now has not been
> > a problem.  The warnming is logged just to be sure, because people
> > keep imprving Berkeley DB.
> >
> >> only a postfix stop, rm verify_cache* , postfix start helps.
> >
> > That is complete and utter overkill.
> 
> so what else is recommended to update the db to have recent data?

Perhaps use the configurable features to control caching of 'negative'
results:

address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h

The 'negative' results are cached to avoid overloading the server
with address verify messages.

I guess that some people can wait for 5 minutes until the negative
cache result has expired?

Wietse

Re: reject_unverified_recipient and /ect/aliases delay/issue

[Noel Jones]

On 9/14/2018 12:41 PM, Stefan Bauer wrote:
> 
> 
> Am Freitag, 14. September 2018 schrieb Wietse Venema :
>> Stefan Bauer:
>>> verify_cache.db seems to get corrupted or at least not updated
> properly as
>>> new/updated entries do not get correctly verified and postfix logs:
>>>
>>> close database /var/lib/postfix/verify_cache.db: No such file or
> directory
>>> > (possible Berkeley DB bug
>>
>> That is logged after 'postfix reload", and until now has not been
>> a problem.  The warnming is logged just to be sure, because people
>> keep imprving Berkeley DB.
>>
>>> only a postfix stop, rm verify_cache* , postfix start helps.
>>
>> That is complete and utter overkill.
> 
> so what else is recommended to update the db to have recent data?


You don't need to do anything other than run newaliases.

Postfix will automatically use the changed the aliases map, so
reload is unnecessary.

The error on closing the database (caused by postfix reload) is an
artifact of Berkeley DB and can be ignored; it does no harm.  With
your environment, you'll likely see that message every time postfix
stops or reloads.



  -- Noel Jones

Re: reject_unverified_recipient and /ect/aliases delay/issue

[Stefan Bauer]

Am Freitag, 14. September 2018 schrieb Wietse Venema :
> Stefan Bauer:
>> verify_cache.db seems to get corrupted or at least not updated properly
as
>> new/updated entries do not get correctly verified and postfix logs:
>>
>> close database /var/lib/postfix/verify_cache.db: No such file or
directory
>> > (possible Berkeley DB bug
>
> That is logged after 'postfix reload", and until now has not been
> a problem.  The warnming is logged just to be sure, because people
> keep imprving Berkeley DB.
>
>> only a postfix stop, rm verify_cache* , postfix start helps.
>
> That is complete and utter overkill.

so what else is recommended to update the db to have recent data?

Re: reject_unverified_recipient and /ect/aliases delay/issue

[Wietse Venema]

Stefan Bauer:
> verify_cache.db seems to get corrupted or at least not updated properly as
> new/updated entries do not get correctly verified and postfix logs:
> 
> close database /var/lib/postfix/verify_cache.db: No such file or directory
> > (possible Berkeley DB bug

That is logged after 'postfix reload", and until now has not been
a problem.  The warnming is logged just to be sure, because people
keep imprving Berkeley DB.

> only a postfix stop, rm verify_cache* , postfix start helps.

That is complete and utter overkill. By the same reasoning you could
claim that it was necessary to reboot the machine, reinstall the
OS, and order new hardware.

Wietse

reject_unverified_recipient and /ect/aliases delay/issue

[Stefan Bauer]

Hi,

we use reject_unverified_recipient and have

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases

after changes in aliases and issuing postalias /etc/aliases

verify_cache.db seems to get corrupted or at least not updated properly as
new/updated entries do not get correctly verified and postfix logs:

close database /var/lib/postfix/verify_cache.db: No such file or directory
> (possible Berkeley DB bug

only a postfix stop, rm verify_cache* , postfix start helps.

are there known limitations?