bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cmu-sieve: starting to work, patch about paths.


From: Alain Magloire
Subject: Re: cmu-sieve: starting to work, patch about paths.
Date: Mon, 28 May 2001 00:34:05 -0400 (EDT)

Bonjour

> > > p.s. I'll mail you or put up for ftp whatever I've done with sieve
> > > by sunday night. Remember, we're talking pre-alpha here, but it
> > > might spark conversation on how it can be used.
> > 
> > Any news on this front?
> 
> Sure, I think it's about a 200k tarred and zipped, who would like
> it mailed to them?

How about to commit it in mailutils/sieve, the old template can go, it
was done in an hour on a rainy day.

> This works:
> 
> ---- t-mailutils.sv --
> require "fileinto";
> 
> if header :contains ["to", "cc"] "address@hidden"
> {
>       fileinto "+l.mailutils";
> }
> ----------------------
> 
> $ sieve -f pop://address@hidden  t-mailutils.sv

Much cool.

> I've spent the day doing a little tweaking, reading through some mailutils
> source, the RFC that I'll need to implement to reject mails, etc. I need
> to do some design work, and there are some API issues.
> 
> I don't want to on at length, briefly:
> 
>  - The mailer API will need to support submission of a message where
>    the envelope from and to is NOT parsed out of the message.

Proposal for the API extension?

> 
>  - I need to find a way to deal with IMAP and POP passwords. In the
>    example I did above I was prompted, this isn't good. Also, the
>    ability to do:
>      fileinto "imap://address@hidden";
>    is critical to me, so I need a way to either:
>
>    1 - outside of the sieve script associate authentication information
>        (what goes in ticket_t, user/pass, commonly) with a URL, maybe
>        in a config file (.netrc? .sieverc?).

How about ${HOME}/.mailpass, without too much effort I can quickly
write(during the week) an auth_t/ticket_t that will fetch the user/pass in
the file and send it.  Should make your life easier?

> 
>    2 - extend the URL syntax to include authorization information. I know
>        the POP url syntax explicitly disallows this (and assume that
>        its the same for IMAP) and I understand and mostly agree with that
>        decision.
>         
>    But... if I can file mail into two imap accounts on the
>    same server, with different passwords for each account, from the

Actually, I think there is a bug in the IMAP client, its trying to be too
smart and will not open a second connection for the second mailbox you
create since it is on the same hostname.  So when you do things like
mailbox_append_message (), it checks the hostanme and maps This to
a COPY command instead of downloading the entire message and resending back
again.  I will not bother correcting this since I'm rewriting the IMAP4 client.
(See other mail on the mailutils documentation).

>    same script, then I need to build a good URL<->ticket_t database
>    somehow. Also, if I do the simple thing which is have the user
>    configure the URL to password mapping in a config file, which will
>    work fine for me when I run a script against the Domino IMAP
>    server what do I do when I take a sieve script and upload it to a
>    good server that supports server-side filtering? The script is
>    no longer so self-contained.

ACAP or maybe RADIUS?

>    There's also no security advantage. The "no passwds in urls" seems
>    to assume urls will be public web pages, this isn't the case for
>    me. Assuming that the user's sieve script, and the possible
>    .sieverc both have permission 0600 in ~/, then there is no security
>    advantage to having the passwords in .sieverc rather than the
>    script, either way they have to be somewher on the system so the
>    script can be run automatically/unattended.

Why not extend sieve to incoporate a new cammand like ":passwd" or something
and put in sieve-scrit.sv:
require "passwd"
require "fileinto";

passwd ~/.mailpass

if header :contains ["to", "cc"] "address@hidden"
{
        fileinto "+l.mailutils";
}

In this specific case,  when you move your sieve script you will have to move
the .mailpass also.

>    
>    This could probably be dealt with with ACAP. ACAP has (it appears from the
>    titles of some of the sieve-related RFCs) been extended to allow the
>    storing of scripts on the server, I guess authentication information
>    could be as well. Still no security advantage though, again we've
>    moved the password out of wherever scripts are stored, to wherever
>    ACAP (or LDAP, or whatever) data is stored.

And even in .mailpass have a redirection to the ACAP server.  Is there
an URL std for ACAP? icap://..

>  - Some other information that seems like configuration info, that might need
>    to be gathered from a file, and thus the config file interface may
>    be useful integrated into mailutils:
> 
>    - which mailer to use, smtp or sendmail <- especially this one
>    - default mailbox
>    - base location for mailboxes (~/Mail, etc.)

Jakob was suppose to come with a generic (mail) configuration scheme ...
but he's a little busy and will be for quite some time 8-(.

> 
> **
> 
> Next on my todo list is tightening up the logging and error reporting,
> it's a little schizophrenic right now, then I'm going to implement
> the redirect command. This will require the mailer to send a message
> to a specified address, not to any of the addresses in to,cc,bcc, and
> I'll also need to deal with configuration to figure out which mailer
> to use.

<Wish>
If you ever tackle the configuration problem, can you try to make it generic
so it can be reuse?

-- 
alain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]