reject_unverified_recipient and /ect/aliases delay/issue

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

reject_unverified_recipient and /ect/aliases delay/issue

Stefan Bauer-2
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?
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: reject_unverified_recipient and /ect/aliases delay/issue

Stefan Bauer-2


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?
Reply | Threaded
Open this post in threaded view
|

Re: reject_unverified_recipient and /ect/aliases delay/issue

Noel Jones-2
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
Reply | Threaded
Open this post in threaded view
|

Re: reject_unverified_recipient and /ect/aliases delay/issue

Wietse Venema
In reply to this post by Stefan Bauer-2
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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: reject_unverified_recipient and /ect/aliases delay/issue

Stefan Bauer-2
In reply to this post by Wietse Venema
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 <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

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