Re: Terminate session after certain SMTP commands

From: Wietse Venema (no email)
Date: Fri Nov 01 2002 - 10:02:06 EST


Michael Tokarev:
> Wietse Venema wrote:
> > Michael Tokarev:
> >
> >>Wietse, what I'm thinking of is - would it be OK to implement e.g.
> >>smtpd_commands_maps parameter, where the key is a command received
> >>by smtpd, and result is TERMINATE to terminate a session, or a reason?
> >>This way, a generalized framework will be available that replaces
> >>already existing one (when postfix closes SMTP session when it sees
> >>email header instead of smtp command).
> >
> > It is not possible to make a generalized framework for tables with
> > commands and actions, because the table would be limited to NOOP
> > and ABORT like actions.
>
> Well, that's not what I wanted (but yes, I know you prefer as much
> general approach as possible, and in fact I too). What I asked for
> is - exactly - to have ability to *block* certain constructs seen
> by smtpd - the rest is already done by postfix. Think about e.g.
> reject_rbl_client vs general-purpose dns map.

Indeed. A too general approach leads to code that is as flexible
and as useful as a rubber screwdriver.

> > Even worse, there is a problem with specifying a table for non-SMTP
> > commands, because its user interface would depend on the private
> > details of how the SMTP command parser tokenizes commands that do
> > not satisfy SMTP syntax. It's no big deal with commands line "GET"
> > but it gets hairy with non-SMTP commands like "Reply-To:foobar".
>
> If smtpd has original line as received from client, that's fine. If
> not, that's fine too - first argument is sufficient in almost all
> cases. Regexp-style map already has all the functionality for this.
>
> /^Reply-To\s*:/ client sent mail header instead of smtpd command
> /^GET\b/ this is not an HTTP server
>
> etc.
>
> Well, the whole question may be minor after all - not much spammers
> are using such ways to delivery their crap, at least for now. Some
> do (or else this question shouldn't exists), but not much, and ther
> is a way to deal with that - by discovering such a systems and by
> submitting them to appropriate blacklists (proxies.relays.monkeys.com
> is one of them).

I am not convinced of the wisdom to send essentially raw network
data through a regexp filter.

        Wietse
-
To unsubscribe, send mail to with content
(not subject): unsubscribe postfix-users








Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD