On 7/9/2010 6:46 AM, Philipp Leusmann wrote:
Am 08.07.2010 um 20:55 schrieb Noel Jones:
On 7/8/2010 12:13 PM, Philipp Leusmann wrote:
thanks for your advice. This really should be pointed out more explicitly in
the documentation.
As for 500, would it be a good practice to return 500, if the key, which in
this case is the email-adress is not known at all?
I also use a local_recipients_map, which already decides if a user exists or
not.
So, which of the both is evaluated first? local_recipient_maps or
smtpd_recipient_restrictions ?
What would be the best practice for my case?
Regards,
Philipp
I expect returning 500 for users under quota or non-existent users would be
appropriate.
Alternately, you could return "200 REJECT" for non-existent users, and "200
DUNNO" for under-quota users.
You probably don't want to use "200 OK" for under-quota users since that will
bypass any further antispam checks you might want to do.
Noel,
I guess at least one "under quota" should read "over quota", doesn't it?
No, my advice is correct as written above.
Returning "no match" for both under quota and non-existent
users should be fine.
When you're using tcp_table as an access map, the possible
results are documented in access(5)
In general it's better to REJECT over-quota recipients rather
than DEFER. The exception would be if you expect the
over-quota users will always clear space in their mailbox
quickly. With REJECT the sender gets immediate feedback that
the recipient didn't receive the message. With DEFER, that
non-delivery notification could be delayed for several days.
Also, is there any any reference documentation about the possible response
string?
For example DUNNO would not be something, which I would try to use naturally.
Also in my logfiles, I notice entries like
warning: restriction `User' after `defer' is ignored
when I return something like
200 DEFER User is over quota
I guess there is some special string expected after DEFER ?
Regards,
Philipp
That sounds as if the table is not being used as an access
map, and postfix is expecting a main.cf restriction with no
text allowed.
