Prev: SASL Authentication per recipient domain
Next: Selective outbound relaying II
From: Noel Jones on 8 Jul 2010 14:55
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.

local_recipient_maps is evaluated at the point you specify
"reject_unlisted_recipient" or at the end of the RCPT TO stage
if you just rely on the default
smtpd_reject_unlisted_recipient setting. So you will get
queries for non-existent recipients.


>>
>
> Sorry for quoting my own mail, but there is one more question: I just implemented Noels suggestuons, and mail get rejected properly now. Thanks for that.
> But I still get the odd
>
> warning: read TCP map reply from localhost:1337: unexpected EOF (Success)
>
> log entry. Is there missing anything?
>
> Regards,
> Philipp

Leave the connection open so postfix can send more queries
over the same connection for better performance. OTOH, this
is a fairly harmless warning.

-- Noel Jones

From: Philipp Leusmann on 9 Jul 2010 07:46

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

From: Wietse Venema on 9 Jul 2010 09:45
Philipp Leusmann:
> 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 ?

No. When the first word is "defer" or "DEFER" etc., then the rest
of the text sent to the client.

Can you show verbose logging of tcp_table when it returns this
result?

Wietse

From: Philipp Leusmann on 9 Jul 2010 09:51
Hi Wietse,

what kind auf verbose logging are you talking about? "postmap -vv -q" ? Or a more verbose logging for tcp_table in mail.log ? How could I turn this on?

Philipp
Am 09.07.2010 um 15:45 schrieb Wietse Venema:

> Philipp Leusmann:
>> 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 ?
>
> No. When the first word is "defer" or "DEFER" etc., then the rest
> of the text sent to the client.
>
> Can you show verbose logging of tcp_table when it returns this
> result?
>
> Wietse

From: Wietse Venema on 9 Jul 2010 10:02
Philipp Leusmann:
> 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 ?

Wietse:
> No. When the first word is "defer" or "DEFER" etc., then the rest
> of the text sent to the client.
>
> Can you show verbose logging of tcp_table when it returns this
> result?

Philipp Leusmann{
> what kind auf verbose logging are you talking about? "postmap -vv
> -q" ? Or a more verbose logging for tcp_table in mail.log ? How
> could I turn this on?

I need to see ONE example of verbose logging that shows

(

tcp_table returning the string that is giving the above error,

AND

the Postfix SMTP server processing that result

).

Wietse

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: SASL Authentication per recipient domain
Next: Selective outbound relaying II