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

From: Wietse Venema on 9 Jul 2010 12:51
Philipp Leusmann:
> > 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
> >
> > ).
>
> Sorry, I still don't get, what you mean.

I need to see VERBOSE LOGGING FROM POSTFIX that shows:

(

tcp_table returning the string that is giving the above error,

AND

the Postfix SMTP server processing that result

).

From: Victor Duchovni on 9 Jul 2010 16:07
On Fri, Jul 09, 2010 at 08:56:38PM +0200, Philipp Leusmann wrote:

> It would be nice, if somebody else, also running a Debian Lenny (it's lenny, not etch) system could verify this behavior.
>
> Anybody here?
>
> I will also reinstall postfix and try again.

If it is compiled with debugging symbols, you could try to single-step
through check_table_result() to see why the "DEFER" case is not matched.

#define STREQUAL(x,y,l) (strncasecmp((x), (y), (l)) == 0 && (y)[l] == 0)

...

if (STREQUAL(value, "DEFER", cmd_len)) {
dsn_split(&dp, "4.7.1", cmd_text);
return (smtpd_check_reject(state, MAIL_ERROR_POLICY,
var_map_defer_code,
smtpd_dsn_fix(DSN_STATUS(dp.dsn),
reply_class),
"<%s>: %s rejected: %s",
reply_name, reply_class,
*dp.text ? dp.text : "Access denied"));
}

So assuming that strncasecmp() is working correctly, the length cmd_len
computed via strcspn() is correct, and your result starts with
"DEFER<SPACE_or_TAB>" (which logs suggest), there is no way to get past
this block and not return before the generic_checks() call lower in the
function.

--
Viktor.

From: Victor Duchovni on 9 Jul 2010 16:17
On Fri, Jul 09, 2010 at 04:04:59PM -0400, Wietse Venema wrote:

> > Either your Postfix source is modified, miscompiled, the binaries are
> > corrupted, or CPU is mal-functioning.
>
> Or he is running a Postfix version before 2.6.
>
> Citing the access(5) manpage:
>
> DEFER optional text...
> Reject the address etc. that matches the pattern. Reply with
> "$access_map_defer_code optional text..." when the optional text
> is specified, otherwise reply with a generic error response mes-
> sage.
>
> This feature is available in Postfix 2.6 and later.

Oops, I thought this was older. He reported running 2.5.5, so that
would explain the whole mess. In 2.5 "DEFER" is not an access(5) action
and so falls through to generic_checks, with the reported symptoms.

--
Viktor.

From: Wietse Venema on 9 Jul 2010 16:37
Victor Duchovni:
> On Fri, Jul 09, 2010 at 04:04:59PM -0400, Wietse Venema wrote:
>
> > > Either your Postfix source is modified, miscompiled, the binaries are
> > > corrupted, or CPU is mal-functioning.
> >
> > Or he is running a Postfix version before 2.6.
> >
> > Citing the access(5) manpage:
> >
> > DEFER optional text...
> > Reject the address etc. that matches the pattern. Reply with
> > "$access_map_defer_code optional text..." when the optional text
> > is specified, otherwise reply with a generic error response mes-
> > sage.
> >
> > This feature is available in Postfix 2.6 and later.
>
> Oops, I thought this was older. He reported running 2.5.5, so that
> would explain the whole mess. In 2.5 "DEFER" is not an access(5) action
> and so falls through to generic_checks, with the reported symptoms.

For the record:

Postfix has always supported

smtpd_mumble_restrictions = ... defer other_restrictions...

And access map lookup results of

... defer other_restrictions...

But only Postfix 2.6 and later support acces map lookup results of

defer optional-text-for-sender

Wietse

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