httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: mod_smtpd: handling rctp addresses
Date Tue, 04 Oct 2005 14:56:17 GMT
On Tuesday 04 October 2005 15:23, Brian J. France wrote:
> I would like to propose a change on how "rcpt to" addresses are
> validated and messages are handled (expanded) and how queue modules
> know it needs to process this message.

How long have you been following mod_smtpd discussion?  The topic of
rcpt to has come up before, with reference to dealing with multiple
recipients.  In my view, we need to be able to treat recipients as
mutually independent - e.g. local or relayed, filtered or not against
spam, viruses, etc.  That implies either running each recipient as a
separate (sub)request or reinventing quite a lot of wheel.

> I would like to change rcpt_to in smtpd_trans_rec to apr_table_t.  The
> key for the table will be the address sent to "rcpt to" command and the
> value will be a pointer to a apr_array_header_t list of pointers to the
> following structure:
>
> typedef struct smtpd_rctp_rec {
> 	apr_pool_t *p;
> 	const char *mode;
> 	int validated;
> 	const char *address;
> 	apr_table_t info;
> 	const char *expanded;
> }

Yow!  That is a new wheel (though a table isn't what you want -
an array with the name as an additional data member would
surely do the job).

Your proposal goes some way towards decoupling different
recipients, but I'm not really convinced.  The basic issue it
doesn't really address is dynamic configuration.  For example,
I want a whitelist or blacklist that may remove all complex
filtering (like mod_spamd) from the chain.  That works fine
at the request level, but in your model it would appear to
imply moving the input filter chain to the smtp_rcpt_rec.

> mode: what queue handler should handle this message.
> 	Example would be local, relay, relay_to, forward, postfix.
>
> validated: if the rctp has been validated and ready to process
>
> address: what address to send to
>
> info: extra data is stored that the queue handler might needed
>
> expanded: log of how the address was expanded

This does look a little like a request, but is not really sufficient.

> Examples:

This is useful thinking-it-through: what you're proposing looks a little
like a subrequest, and might ultimately make more sense.  But it'll
need at least that move of the input filter chain!

-- 
Nick Kew

Mime
View raw message