Am 08.07.2010 um 20:55 schrieb Noel Jones: > On 7/8/2010 12:13 PM, Philipp Leusmann wrote: >> >> Am 08.07.2010 um 19:02 schrieb Philipp Leusmann: >> >>> >>> Am 08.07.2010 um 18:23 schrieb Noel Jones: >>> >>>> On 7/8/2010 10:58 AM, Philipp Leusmann wrote: >>>>> Hi all, >>>>> >>>>> to stop backscattering I wrote a tcp_table server which checks quota >>>>> availability for incoming messages. >>>>> I read<http://www.postfix.org/tcp_table.5.html> over and over again, >>>>> but still I am getting messages like >>>>> >>>>> Jul 8 17:46:24 s15277780 postfix/smtpd[3325]: warning: read TCP map >>>>> reply from localhost:1337: unexpected EOF (Success) >>>>> Jul 8 17:46:25 s15277780 postfix/smtpd[3325]: warning: >>>>> tcp:localhost:1337: table lookup problem >>>>> >>>>> >>>>> in the logfile, when the server returns a 400 or 500 reply. For a >>>>> 200-reply it works ok and the mail is delivered. >>>>> >>>>> For a 400-reply, my server generates the following (from my logfile): >>>>> >>>>> The encoded reply is [400 User%20over%20quota >>>>> ] >>>>> >>>>> >>>>> The server sends everything between [ and ] . I think that should be ok. >>>>> Or isn't it? >>>>> >>>>> >>>>> When I try a >>>>> >>>>> postmap -vv -q "benny" tcp:localhost:1337 >>>>> >>>>> (benny is over quota) >>>>> >>>>> the output ends with: >>>>> >>>>> postmap: loaded dict_tcp_open = 7f50d057bd20 >>>>> postmap: dict_open: calling tcp open routine >>>>> postmap: dict_open: tcp:localhost:1337 >>>>> postmap: dict_tcp_lookup: key benny >>>>> postmap: trying... [127.0.0.1] >>>>> postmap: dict_tcp_lookup: send: get benny >>>>> postmap: dict_tcp_lookup: recv: 400 User%20over%20quota >>>>> postmap: dict_tcp_lookup: soft error: 400 User%20over%20quota >>>>> >>>>> For a user having available space, it looks like: >>>>> >>>>> postmap: loaded dict_tcp_open = 7f30f5c76d20 >>>>> postmap: dict_open: calling tcp open routine >>>>> postmap: dict_open: tcp:localhost:1337 >>>>> postmap: dict_tcp_lookup: key laus >>>>> postmap: trying... [127.0.0.1] >>>>> postmap: dict_tcp_lookup: send: get laus >>>>> postmap: dict_tcp_lookup: recv: 200 OK >>>>> postmap: dict_tcp_lookup: found: OK >>>>> OK >>>>> >>>>> >>>>> >>>>> Can anybody tell me, what is wrong? >>>>> >>>>> And what does postfix return the the delivering client in my current >>>>> case? a 500 ? >>>>> >>>>> Regards, >>>>> Philipp >>>> >>>> The 200, 400, and 500 codes indicate the status of the lookup itself, and >>>> do not indicate the result. >>>> >>>> 200, the lookup found something, here it is: (OK, DEFER, REJECT ... other >>>> access(5) actions) >>>> 400, the lookup table is broken, try later >>>> 500, the key wasn't found >>>> >>>> In the case of an over-quota user, your table should return >>>> 200 REJECT User over quota >>>> or DEFER if that's the action you want. >>>> >>>> This isn't documented explicitly in the README because tcp tables can be >>>> used for purposes other than access maps. >>>> >>>> -- Noel Jones >>> >>> Noel, >>> >>> 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? 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
