Hi Sam,

it's been a while since the "Newsletter with courier-mlm" thread died, but
since then I've thought about tracking authentication information in
courierfilters.  To rehash, I'll quote a bit:

Peter <[EMAIL PROTECTED]> wrote:
> OK, please let me repeat. It would be nice if all others interested in
> this could check this.
>
> the goal is to configure a newsletter, that only can be posted to by
> one person, the newsletter author. the list should be maintanance
> free, so we don?t want to use moderation.
>
> Also we don?t want to use any kind of "secret address" or any
> "security by obscurity" model for the allowed posting addresses.
>
> The trick will be to creat a .courier file in the mailinglist account
> home directory (right?) which checks the SECOND line of the FIRST
> "received:" - header. In this line there will be two important
> informations: the AUTH method and the account that posted this
> messages. it could look like this:
>
>  (AUTH: CRAM-MD5 [EMAIL PROTECTED])
>
> At least that?s what I see in the headers.
>
> This part of the header can not be forged, as it is generated by
> courier. But we have to assure that it really is the SECOND line of the
> FIRST received header.
>
> [...]

Sam Varshavchik <[EMAIL PROTECTED]> wrote:
> Julian Mehnle writes:
> > Sam Varshavchik <[EMAIL PROTECTED]> wrote:
> > > A succesfull SMTP authentication will have stuff record in headers.
> >
> > Ah, so it seems I was in error.  Sam, is it possible to fake
> > these headers in messages submitted to Courier through SMTP?
>
> No, as long as you are careful to only look at the second line of the
> very first Received: header; and you ignore all other Received: headers.

Now, I'm working on "pureperlfilter", a purely Perl-based courierfilter
framework, similar to Gordon Messmer's pythonfilter.

I'd like to allow filter modules to know whether a given message has been
submitted to Courier through a trusted channel, e.g. authenticated SMTP.
For instance, the DNSBL filter module I have written[1] would need to know
whether a message's source can be trusted or should be checked against the
configured DNSBLs.

I know I can extract the authentication information from the second line
of the first "Received:" header line of the message.  But I consider that
not very robust, and it's somewhat complicated when the message's header
lines have already been unwrapped.

So I wonder whether it would be a good idea to store that authentication
(or relay authorization) information in a new "a" record type in the
message's control file?  I know that there are already some convenience
record types, like "8", which "can be used ... for optimization", so this
would be somewhat analogous.  What do you think?

[1] I know one can do DNSBL blocking out of the box using the esmtpd
BLACKLISTS configuration option, but I'd like to (a) customize the
response messages, (b) learn the subjects of the rejected messages, and
(c) log rejections in a more complete and structured manner than just
syslog.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to