verify parameters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

verify parameters

Egoitz Aurrekoetxea Aurre
Hi,

I'm using a postfix mail scanning machine for doing relay to another
server wich stores user mailboxes and has his own smtp (a cpanel machine).

Like domain admins could create or delete mail accounts I have enabled in
my postfix scanning machine reject_unverified_recipient. Have done some
checks and have this settings in main.cf file:

address_verify_positive_refresh_time = 3m
address_verify_positive_expire_time = 8m
address_verify_negative_refresh_time = 5m
address_verify_negative_expire_time = 10m


Have done this test :

create a mail account, send a mail to him through postfix (so it should be
positive cached) later remove the mail account (so waiting supposed 3 m it
should be negatively cached) that didn't occur and had to wait more or
less 20 minutes for it be negatively cached... after that I created it and
more or less in 5 minutes it was positively cached again...

so is there any minimum time for positive caching??? the main.cf
explanation of postfix.org (http://www.postfix.org/postconf) doesn't
explain something about minimum values? do they exist??

Why is not this advised for high traffic sites (as said in man pages)? I
think this is an ideal solution for scanning machines in ISP's in wich you
can't know wich recipients are in the other place...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Matthias Haegele-2
[hidden email] schrieb:

> Hi,
>
> I'm using a postfix mail scanning machine for doing relay to another
> server wich stores user mailboxes and has his own smtp (a cpanel machine).
>
> Like domain admins could create or delete mail accounts I have enabled in
> my postfix scanning machine reject_unverified_recipient. Have done some
> checks and have this settings in main.cf file:
>
> address_verify_positive_refresh_time = 3m
> address_verify_positive_expire_time = 8m
> address_verify_negative_refresh_time = 5m
> address_verify_negative_expire_time = 10m

I think these values are far too low (if not intended for testing only).
Maybe you want to use address_verify_map too ...

> Have done this test :
>
> create a mail account, send a mail to him through postfix (so it should be
> positive cached) later remove the mail account (so waiting supposed 3 m it
> should be negatively cached) that didn't occur and had to wait more or
> less 20 minutes for it be negatively cached... after that I created it and
> more or less in 5 minutes it was positively cached again...
>
> so is there any minimum time for positive caching??? the main.cf

The docs dont mention a minimum time:
http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time

> explanation of postfix.org (http://www.postfix.org/postconf) doesn't
> explain something about minimum values? do they exist??

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

> Why is not this advised for high traffic sites (as said in man pages)? I
> think this is an ideal solution for scanning machines in ISP's in wich you
> can't know wich recipients are in the other place...

Cause it binds ressources since the address probes need to be sent for
every unknown address.

Some ISPs would block you after several hundred address probes at a
given time.

(maybe there are problems with Mailinglists too which use
one-time-mailadresses for sending)



hth

--
Gruesse/Greetings
MH


Dont send mail to: [hidden email]
--

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Wietse Venema
In reply to this post by Egoitz Aurrekoetxea Aurre
[hidden email]:

> Hi,
>
> I'm using a postfix mail scanning machine for doing relay to another
> server wich stores user mailboxes and has his own smtp (a cpanel machine).
>
> Like domain admins could create or delete mail accounts I have enabled in
> my postfix scanning machine reject_unverified_recipient. Have done some
> checks and have this settings in main.cf file:
>
> address_verify_positive_refresh_time = 3m
> address_verify_positive_expire_time = 8m
> address_verify_negative_refresh_time = 5m
> address_verify_negative_expire_time = 10m
>
>
> Have done this test :
>
> create a mail account, send a mail to him through postfix (so it should be
> positive cached) later remove the mail account (so waiting supposed 3 m it
> should be negatively cached)

AS DOCUMENTED the refresh time does not work that way.
http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time

> that didn't occur and had to wait more or
> less 20 minutes for it be negatively cached... after that I created it and
> more or less in 5 minutes it was positively cached again...

AS DOCUMENTED the expire works that way.
http://www.postfix.org/postconf.5.html#address_verify_positive_expire_time

The mailing list is not a substitute for reading the documentation.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Egoitz Aurrekoetxea Aurre
Hi Wietse!

Have read the documentation some times now... perhaps my english is not
good, perhaps I don't easily understand things but I have read the doc
unless 5 times (really) for this parameters... And finally have done this
tests for seeing if I understand all...

It's all what I could do for understanding this doc... really...



> [hidden email]:
>> Hi,
>>
>> I'm using a postfix mail scanning machine for doing relay to another
>> server wich stores user mailboxes and has his own smtp (a cpanel
>> machine).
>>
>> Like domain admins could create or delete mail accounts I have enabled
>> in
>> my postfix scanning machine reject_unverified_recipient. Have done some
>> checks and have this settings in main.cf file:
>>
>> address_verify_positive_refresh_time = 3m
>> address_verify_positive_expire_time = 8m
>> address_verify_negative_refresh_time = 5m
>> address_verify_negative_expire_time = 10m
>>
>>
>> Have done this test :
>>
>> create a mail account, send a mail to him through postfix (so it should
>> be
>> positive cached) later remove the mail account (so waiting supposed 3 m
>> it
>> should be negatively cached)
>
> AS DOCUMENTED the refresh time does not work that way.
> http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time
>
>> that didn't occur and had to wait more or
>> less 20 minutes for it be negatively cached... after that I created it
>> and
>> more or less in 5 minutes it was positively cached again...
>
> AS DOCUMENTED the expire works that way.
> http://www.postfix.org/postconf.5.html#address_verify_positive_expire_time
>
> The mailing list is not a substitute for reading the documentation.
>
> Wietse
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Egoitz Aurrekoetxea Aurre
In reply to this post by Egoitz Aurrekoetxea Aurre
helo!

for example this were the problems I had :


"address_verify_positive_refresh_time (default: 7d)
The time after which a successful address verification probe needs to be
refreshed. The address verification status is not updated when the probe
fails (optimistic caching). "

When a probe fails means that the probe hasn't finished totally (because
the server is not reachable OR the servers gives other errors such as
server configuration problem) or is when the remote server gives you a no
such recipient... this is my first doubt

"address_verify_positive_expire_time (default: 31d)
The time after which a successful probe expires from the address
verification cache. "

Here for example I assume that when a recipient is cached because
destination machine has said OK that record expires in 31 days... BUT
expires if it hasn't been refreshed or just expires even having been
refreshed???

"address_verify_negative_refresh_time (default: 3h)
The time after which a failed address verification probe needs to be
refreshed. "

a failed address verification probe means a recipient for wich destination
server (the server who we query if address exist or not) has rejected
because the address doesn't exist OR a probe that hasn't been possible to
finish for other reasons same as in address_verify_positive_refresh_time??

Perhaps this all in my english but this is what I didn't understand when I
read... could you please clarify this?


thannks a lot mates!

see u!
> Hi Wietse!
>
> Have read the documentation some times now... perhaps my english is not
good, perhaps I don't easily understand things but I have read the doc
unless 5 times (really) for this parameters... And finally have done this
tests for seeing if I understand all...
>
> It's all what I could do for understanding this doc... really...
>
>
>
>> [hidden email]:
>>> Hi,
>>>
>>> I'm using a postfix mail scanning machine for doing relay to another
server wich stores user mailboxes and has his own smtp (a cpanel
machine).
>>>
>>> Like domain admins could create or delete mail accounts I have enabled
in my postfix scanning machine reject_unverified_recipient. Have done
some checks and have this settings in main.cf file:

>>>
>>> address_verify_positive_refresh_time = 3m
>>> address_verify_positive_expire_time = 8m
>>> address_verify_negative_refresh_time = 5m
>>> address_verify_negative_expire_time = 10m
>>>
>>>
>>> Have done this test :
>>>
>>> create a mail account, send a mail to him through postfix (so it
should be
>>> positive cached) later remove the mail account (so waiting supposed 3
m it
>>> should be negatively cached)
>>
>> AS DOCUMENTED the refresh time does not work that way.
>> http://www.postfix.org/postconf.5.html#address_verify_positive_refresh_time
>>
>>> that didn't occur and had to wait more or
>>> less 20 minutes for it be negatively cached... after that I created it
and

>>> more or less in 5 minutes it was positively cached again...
>>
>> AS DOCUMENTED the expire works that way.
>> http://www.postfix.org/postconf.5.html#address_verify_positive_expire_time
>>
>> The mailing list is not a substitute for reading the documentation.
>>
>> Wietse
>>
>
>







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Wietse Venema
[hidden email]:
> helo!
>
> for example this were the problems I had :
>
>
> "address_verify_positive_refresh_time (default: 7d)
> The time after which a successful address verification probe needs to be
> refreshed. The address verification status is not updated when the probe
> fails (optimistic caching). "

Success = the user exists. Failure = everything else.

> "address_verify_positive_expire_time (default: 31d)
> The time after which a successful probe expires from the address
> verification cache. "
>
> Here for example I assume that when a recipient is cached because
> destination machine has said OK that record expires in 31 days... BUT
> expires if it hasn't been refreshed or just expires even having been
> refreshed???

A probe that was sent at time T will expire after time (T + expire).
There is nothing magical about the refresh operation. It simply means
"send another probe".

> "address_verify_negative_refresh_time (default: 3h)
> The time after which a failed address verification probe needs to be
> refreshed. "

A probe that was sent at time T needs to be refreshed after time (T + refresh).

> a failed address verification probe means a recipient for wich destination
> server (the server who we query if address exist or not) has rejected
> because the address doesn't exist OR a probe that hasn't been possible to
> finish for other reasons same as in address_verify_positive_refresh_time??

Success = the user exists. Failure = everything else.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Egoitz Aurrekoetxea Aurre
Hi Wietse!!!

First of all very thanked by you're answers, really. thank you very much.
Have been reading you're mail and re-reading this parameters in
postfix.org doc and have reached to two conclusions :

1.- If cache records (each recipient checked and set as exists or not)
expire anyway in time T + expire... then why do we use refresh too? I say
this because in positive refresh if the result is fail (so anything not
saying user exists) like cache is optimistic caching the result is not
updated... so the only way (if I'm not confused) to update this result is
waiting till it expires from cache, so what do we need then refresh for
positive cache?

2.- Refresh and expire have nothing to do each one with another... (it's
not like in bind in wich a zone should be refreshed from master or it
expires).

Well I assume I will set address_verify_negative_cache to no... because in
my experience unless most of negative responses are due to spammers using
dictionaries so probably a non-existent-recipient perhaps is not being
asked again.... so... perhaps I will only do positive caching...

Thanks a lot Wietse.
Bye!

> [hidden email]:
>> helo!
>>
>> for example this were the problems I had :
>>
>>
>> "address_verify_positive_refresh_time (default: 7d)
>> The time after which a successful address verification probe needs to be
>> refreshed. The address verification status is not updated when the probe
>> fails (optimistic caching). "
>
> Success = the user exists. Failure = everything else.
>
>> "address_verify_positive_expire_time (default: 31d)
>> The time after which a successful probe expires from the address
>> verification cache. "
>>
>> Here for example I assume that when a recipient is cached because
>> destination machine has said OK that record expires in 31 days... BUT
>> expires if it hasn't been refreshed or just expires even having been
>> refreshed???
>
> A probe that was sent at time T will expire after time (T + expire).
> There is nothing magical about the refresh operation. It simply means
> "send another probe".
>
>> "address_verify_negative_refresh_time (default: 3h)
>> The time after which a failed address verification probe needs to be
>> refreshed. "
>
> A probe that was sent at time T needs to be refreshed after time (T +
> refresh).
>
>> a failed address verification probe means a recipient for wich
>> destination
>> server (the server who we query if address exist or not) has rejected
>> because the address doesn't exist OR a probe that hasn't been possible
>> to
>> finish for other reasons same as in
>> address_verify_positive_refresh_time??
>
> Success = the user exists. Failure = everything else.
>
> Wietse
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Wietse Venema
[hidden email]:
> Hi Wietse!!!
>
> First of all very thanked by you're answers, really. thank you very much.
> Have been reading you're mail and re-reading this parameters in
> postfix.org doc and have reached to two conclusions :
>
> 1.- If cache records (each recipient checked and set as exists or not)
> expire anyway in time T + expire... then why do we use refresh too? I say

The concepts of caching, expiration and refresh were invented before
most people on the Internet were born.  For example, they are the
basis for the DNS protocol.

In the case of Postfix,

- Refresh means you don't have to wait until the probe completes.

- Expire means you know nothing until the probe completes.

If you want to learn how cache algorithms work, The Postfix list
is not the right forum.

        Wietse

> this because in positive refresh if the result is fail (so anything not
> saying user exists) like cache is optimistic caching the result is not
> updated... so the only way (if I'm not confused) to update this result is
> waiting till it expires from cache, so what do we need then refresh for
> positive cache?
>
> 2.- Refresh and expire have nothing to do each one with another... (it's
> not like in bind in wich a zone should be refreshed from master or it
> expires).
>
> Well I assume I will set address_verify_negative_cache to no... because in
> my experience unless most of negative responses are due to spammers using
> dictionaries so probably a non-existent-recipient perhaps is not being
> asked again.... so... perhaps I will only do positive caching...
>
> Thanks a lot Wietse.
> Bye!
>
> > [hidden email]:
> >> helo!
> >>
> >> for example this were the problems I had :
> >>
> >>
> >> "address_verify_positive_refresh_time (default: 7d)
> >> The time after which a successful address verification probe needs to be
> >> refreshed. The address verification status is not updated when the probe
> >> fails (optimistic caching). "
> >
> > Success = the user exists. Failure = everything else.
> >
> >> "address_verify_positive_expire_time (default: 31d)
> >> The time after which a successful probe expires from the address
> >> verification cache. "
> >>
> >> Here for example I assume that when a recipient is cached because
> >> destination machine has said OK that record expires in 31 days... BUT
> >> expires if it hasn't been refreshed or just expires even having been
> >> refreshed???
> >
> > A probe that was sent at time T will expire after time (T + expire).
> > There is nothing magical about the refresh operation. It simply means
> > "send another probe".
> >
> >> "address_verify_negative_refresh_time (default: 3h)
> >> The time after which a failed address verification probe needs to be
> >> refreshed. "
> >
> > A probe that was sent at time T needs to be refreshed after time (T +
> > refresh).
> >
> >> a failed address verification probe means a recipient for wich
> >> destination
> >> server (the server who we query if address exist or not) has rejected
> >> because the address doesn't exist OR a probe that hasn't been possible
> >> to
> >> finish for other reasons same as in
> >> address_verify_positive_refresh_time??
> >
> > Success = the user exists. Failure = everything else.
> >
> > Wietse
> >
>
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Terry Carmen
Wietse Venema wrote:
> The concepts of caching, expiration and refresh were invented before
> most people on the Internet were born.  For example, they are the
> basis for the DNS protocol.
>  

Now you're making me feel old.

I remember when UUCP involved modems.

Terry


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Egoitz Aurrekoetxea Aurre
In reply to this post by Wietse Venema
Hi Wietse!!!!

first of all thank you for answering and having this patience. Have been
again reading slowly you're mails, the doc and doing some checks before
writting...

but :

> [hidden email]:
>> Hi Wietse!!!
>>
>> First of all very thanked by you're answers, really. thank you very
>> much.
>> Have been reading you're mail and re-reading this parameters in
>> postfix.org doc and have reached to two conclusions :
>>
>> 1.- If cache records (each recipient checked and set as exists or not)
>> expire anyway in time T + expire... then why do we use refresh too? I
>> say
>
> The concepts of caching, expiration and refresh were invented before
> most people on the Internet were born.  For example, they are the
> basis for the DNS protocol.

I know but there I can understand concepts because when you're a slave
zone if unless one refresh hasn't happened in the period of time of the
expiry time value the zone is disconnected... and refresh is used to
update slave zones... or when you're caching refresh time means how many
time you could pass to clients the last obtained value from the
authoritive server without updating it...


But here for example in positive caching can't understand why is used for
a refresh parameter because if the probe fails the status is not
updated... so what is used for the refresh? because If I read well I see
in previous mails that in postfix verify cache expiry time just arrives
after T + expiry time, nothing to do with refreshes (as in dns)... so why
are we refreshing positive cached values? I could understand the refresh
in negative caching but in positive? why is done in positive caching a
refresh if status of the recipient is not updated if probe fails and
expiry time is fixed since the value was entered in the verify table?

And have done some checks with this values :

address_verify_map = btree:/etc/postfix/tablaverify
address_verify_positive_refresh_time = 3m
address_verify_positive_expire_time = 5m
address_verify_negative_cache = no

(the values are very low I know but I'm just testing it...)

I send an email to a non existing address ([hidden email], of course supposing
a.es is hosted domain of my destination server) it's rejected, ok till
here. Now I create [hidden email], nice because the mail is automatically accepted
so negative_cache is disable as we said... I do an ls -l
/etc/postfix/tablaverify.db and see it's last modification time is 12:08
now I remove [hidden email] (are 12:09 more or less) from mailbox server (the
destination I mean) and continue sending mails to [hidden email] from the postfix
scanning machine... the caching file is updated at 12:11.

 postmap -s btree:/etc/postfix/tablaverify outputs :

[hidden email]  0:0:1210500473:250 Accepted
[hidden email]  0:0:1210500476:250 Accepted
[hidden email]  0:1210500663:1210500479:250 Accepted
[hidden email]  0:0:1210500482:250 Accepted

now continue sending mails to this non existing recipient (and see how
bounces arrive because it's accepted but doesn't exist [hidden email]...)...

the file continues without being updated (optimistic caching as doc sais,
so till here well) but expiration time doesn't arrive because time is
12:26 and can sending mails to [hidden email] (I send one mail per minute more or
less since I removed the recipient to see how bounces arrives) without
being rejected at smtp time... all of them are bounced... if expiry time
is 5m shouldn't it be expired from the verify btree cache table at 12:13
(because the value was entered at 12:08 as we said and expiry is 5m)?

now are 12:29 I tried sending again a mail to [hidden email] and it's rejected
nice... but I removed it more or less at 12:09 have passed more or less 20
minutes... is it a minimum period of time for this values? because
positive expire is set to 5m and have passed more or less 20 (because
value was entered at 12:08 in database too)...


>
> In the case of Postfix,
>
> - Refresh means you don't have to wait until the probe completes.
>
> - Expire means you know nothing until the probe completes.
>


> If you want to learn how cache algorithms work, The Postfix list
> is not the right forum.

No, no Wietse I just want to make reject_unverfied_recipient to work for
avoid spamming the world when spammers send mail to one of my domains and
the user doesn't exist. There are various ISP in wich they accept all mail
and later bounce it... I don't like this solution... that's all really, I
don't want you to teach me something that I should learn by myself or
something like that, really mates. I'm just worried about spam, and can't
get a list of valid recipients from my customers, it's totally impossible
I tried it...



Thanks a lot very very really.
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Egoitz Aurrekoetxea Aurre
I'm running postfix 2.3.8, debian etch postfix package

> Hi Wietse!!!!
>
> first of all thank you for answering and having this patience. Have been
> again reading slowly you're mails, the doc and doing some checks before
> writting...
>
> but :
>
>> [hidden email]:
>>> Hi Wietse!!!
>>>
>>> First of all very thanked by you're answers, really. thank you very
>>> much.
>>> Have been reading you're mail and re-reading this parameters in
>>> postfix.org doc and have reached to two conclusions :
>>>
>>> 1.- If cache records (each recipient checked and set as exists or not)
>>> expire anyway in time T + expire... then why do we use refresh too? I
>>> say
>>
>> The concepts of caching, expiration and refresh were invented before
>> most people on the Internet were born.  For example, they are the
>> basis for the DNS protocol.
>
> I know but there I can understand concepts because when you're a slave
> zone if unless one refresh hasn't happened in the period of time of the
> expiry time value the zone is disconnected... and refresh is used to
> update slave zones... or when you're caching refresh time means how many
> time you could pass to clients the last obtained value from the
> authoritive server without updating it...
>
>
> But here for example in positive caching can't understand why is used for
> a refresh parameter because if the probe fails the status is not
> updated... so what is used for the refresh? because If I read well I see
> in previous mails that in postfix verify cache expiry time just arrives
> after T + expiry time, nothing to do with refreshes (as in dns)... so why
> are we refreshing positive cached values? I could understand the refresh
> in negative caching but in positive? why is done in positive caching a
> refresh if status of the recipient is not updated if probe fails and
> expiry time is fixed since the value was entered in the verify table?
>
> And have done some checks with this values :
>
> address_verify_map = btree:/etc/postfix/tablaverify
> address_verify_positive_refresh_time = 3m
> address_verify_positive_expire_time = 5m
> address_verify_negative_cache = no
>
> (the values are very low I know but I'm just testing it...)
>
> I send an email to a non existing address ([hidden email], of course supposing
> a.es is hosted domain of my destination server) it's rejected, ok till
> here. Now I create [hidden email], nice because the mail is automatically accepted
> so negative_cache is disable as we said... I do an ls -l
> /etc/postfix/tablaverify.db and see it's last modification time is 12:08
> now I remove [hidden email] (are 12:09 more or less) from mailbox server (the
> destination I mean) and continue sending mails to [hidden email] from the postfix
> scanning machine... the caching file is updated at 12:11.
>
>  postmap -s btree:/etc/postfix/tablaverify outputs :
>
> [hidden email]  0:0:1210500473:250 Accepted
> [hidden email]  0:0:1210500476:250 Accepted
> [hidden email]  0:1210500663:1210500479:250 Accepted
> [hidden email]  0:0:1210500482:250 Accepted
>
> now continue sending mails to this non existing recipient (and see how
> bounces arrive because it's accepted but doesn't exist [hidden email]...)...
>
> the file continues without being updated (optimistic caching as doc sais,
> so till here well) but expiration time doesn't arrive because time is
> 12:26 and can sending mails to [hidden email] (I send one mail per minute more or
> less since I removed the recipient to see how bounces arrives) without
> being rejected at smtp time... all of them are bounced... if expiry time
> is 5m shouldn't it be expired from the verify btree cache table at 12:13
> (because the value was entered at 12:08 as we said and expiry is 5m)?
>
> now are 12:29 I tried sending again a mail to [hidden email] and it's rejected
> nice... but I removed it more or less at 12:09 have passed more or less 20
> minutes... is it a minimum period of time for this values? because
> positive expire is set to 5m and have passed more or less 20 (because
> value was entered at 12:08 in database too)...
>
>
>>
>> In the case of Postfix,
>>
>> - Refresh means you don't have to wait until the probe completes.
>>
>> - Expire means you know nothing until the probe completes.
>>
>
>
>> If you want to learn how cache algorithms work, The Postfix list
>> is not the right forum.
>
> No, no Wietse I just want to make reject_unverfied_recipient to work for
> avoid spamming the world when spammers send mail to one of my domains and
> the user doesn't exist. There are various ISP in wich they accept all mail
> and later bounce it... I don't like this solution... that's all really, I
> don't want you to teach me something that I should learn by myself or
> something like that, really mates. I'm just worried about spam, and can't
> get a list of valid recipients from my customers, it's totally impossible
> I tried it...
>
>
>
> Thanks a lot very very really.
>>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verify parameters

Wietse Venema
In reply to this post by Egoitz Aurrekoetxea Aurre
[hidden email]:

> > In the case of Postfix,
> >
> > - Refresh means you don't have to wait until the probe completes.
> >
> > - Expire means you know nothing until the probe completes.
>
> > If you want to learn how cache algorithms work, The Postfix list
> > is not the right forum.
>
> No, no Wietse I just want to make reject_unverfied_recipient to work for
> avoid spamming the world when spammers send mail to one of my domains and
> the user doesn't exist. There are various ISP in wich they accept all mail
> and later bounce it... I don't like this solution... that's all really, I
> don't want you to teach me something that I should learn by myself or
> something like that, really mates. I'm just worried about spam, and can't
> get a list of valid recipients from my customers, it's totally impossible
> I tried it...

You totally botched it by mis-configuring the expire and refresh
timerswith settings of minutes.

To make this work

- you MUST use a persistent address verification database.

- you MUST use a positive expire time of days if not weeks.

- you MUST use a positive refresh time that is not small compared
  to the positive expire time.

- you MUST use a short negative expire time of at least an hour.

- you MUST use a negative expire time that is not small compared
  to the negative expire time.

In other words, use the defaults until you understand how things
work.

        Wietse

Loading...