What's concerning me actually does appear to be a difference in the
command-line interface. With the deliver binary from my 1.5.2 build, I can
do:
$ deliver -a malallen -m user.malallen.test < some.msg
and the mail will be delivered directly to the user.malallen.test mailbox.
I can't get this to work with the deliver binary in 2.0.9.
Between trussing deliver and lmtpd and reading through deliver.c, it looks
to me like delivery into non-top-level mailboxes is supposed to be done with
some sort of "<user>+<mailbox>" syntax for lmtpd. So, the command above
results in a RCPT address of "<+user.malallen.test>" given to lmtpd.
And lmtpd apparently doesn't have any idea what to do with an address
starting with a "+".
My questions are:
1) where can I find a specification of this syntax which deliver is using
with lmtpd (the LMTP and SMTP rfc's don't appear to cover it)?
2) Is the man page entry for deliver incorrect? Concerning the -m
switch, it states:
-m mailbox
Deliver to mailbox. If any userids are specified,
attempts to deliver to user.userid.mailbox for each
userid. If the ACL on any such mailbox does not grant
the sender the "p" right or if -m is not specified,
then delivers to the INBOX for the userid, regardless
of the ACL on the INBOX.
If no userids are specified, attempts to deliver to
mailbox. If the ACL on mailbox does not grant the
sender the "p" right, the delivery fails.
The behavior I'm seeing doesn't appear to agree with what is described in
this document.
Thanks in advance for any help.
--
Matt Allen
Messaging Team
UITS
(812) 855 8858
Ken Murchison said:
>
>
> Werner Reisberger wrote:
> >
> > Quoting Mobeen Azhar <[EMAIL PROTECTED]>:
> >
> > > I have not been able to use deliver since I upgraded from 1.5 to 2.x.
> > > and
> > > had to revert to using sieve.
> >
> > It's written in the upgrade notice, that deliver is only a wrapper to
> > the lmtp server and that a lmtp client is required.
>
> This is NOT true. Deliver's sole purpose in life in 2.x is so that you
> do NOT need an LMTP client. It provides the same command line interface
> as in 1.6 and still injects messages into the mailstore. The only
> difference is that in 2.x it talks to lmtpd instead of dealing with the
> mailstore directly.
>
> > I also have a filtering system with procmail (including web frontend
> > for the users) and don't want to learn the sieve language and reconfigure
> > everything new if I can avoid it. But currently I cannot upgrade to
> > 2.x because procmail isn't available as lmtp client (there is a beta
> > version able to act as lmtp server).
> >
> > I don't know what's the best solution for me and what's feasible:
> >
> > - drop procmail completly
> > - replace deliver/lmtpd with something supporting non-lmtp clients
> > - write code for procmail to act as lmtp client
>
> You should be able to use your current config. If not, either you're
> misconfigured or there is a bug in deliver. I'm guessing the former.
>
>
