(Using dovecot 1.0 RC7 on Fedora Core 5)
<scene set>
Hitherto we have used UW-IMAP on a "farm" of Linux machines mounting
NFS
from a NetApp. (The UW-IMAP author doesn't like use of NFS, but with
careful use of NFS mount arguments ('noac,actimeo=0' etc.) and trying to
ensure that all activity for a given user takes place within one machine
in the farm, we seem to have been OK.) We have also used UW-IMAP's
'tmail' (in sendmail.cf) and 'dmail' (from any user procmail
recipes), so
that access to the INBOX has been consistently UW-IMAP software.
We are now considering doing a transparent migration to dovecot to improve
performance.
</scene>
---
First: a general question: To complement the UW->dovecot migration of the
IMAP daemon (reading the INBOX and folders), ought I to do a similar
delivery-side migration from [UW] tmail/dmail to [dovecot] 'deliver'?
It would feel safer this way, but maybe I worry too much...
---
Second: "deliver" seems to add an unconditional "From " line
at the start
of each delivery. From sendmail, using the 'n' flag, "Mlocal
F=...n..."
that is OK. (Although I'm not convinced that "dovecot.deliver",
nor its
two-space separator (emphasis on "two") from the following date are
ideal. Nor, come to that line's lack of "@somewhere".)
But from a procmail recipe, I end up with two "From " lines. Surely
this
is incorrect. How can this be reduced to one? Shouldn't
"deliver" ensure
that there is only "From " line?
---
Third: Would it be possible for "deliver" to do a "syslog"
entry to
confirm final delivery into the destination mailbox, please? (I could try
and produce a patch, but someone else with more dovecot familiarity could
probably do the job must more quickly and probably also more cleanly!)
(I think that's all for the moment.)
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
Hello! Try my patch from: http://dovecot.org/pipermail/dovecot/2006-July/014656.html You can use dovecots deliver program with procmail, it also trips the from lines. It works well for me since July 2006. Logging is done through the procmail logging. Ciao, Gerhard -- http://www.wiesinger.com/ On Tue, 3 Oct 2006, David Lee wrote:> (Using dovecot 1.0 RC7 on Fedora Core 5) > > > <scene set> > > Hitherto we have used UW-IMAP on a "farm" of Linux machines mounting NFS > from a NetApp. (The UW-IMAP author doesn't like use of NFS, but with > careful use of NFS mount arguments ('noac,actimeo=0' etc.) and trying to > ensure that all activity for a given user takes place within one machine > in the farm, we seem to have been OK.) We have also used UW-IMAP's > 'tmail' (in sendmail.cf) and 'dmail' (from any user procmail recipes), so > that access to the INBOX has been consistently UW-IMAP software. > > We are now considering doing a transparent migration to dovecot to improve > performance. > > </scene> > > --- > First: a general question: To complement the UW->dovecot migration of the > IMAP daemon (reading the INBOX and folders), ought I to do a similar > delivery-side migration from [UW] tmail/dmail to [dovecot] 'deliver'? > It would feel safer this way, but maybe I worry too much... > > --- > Second: "deliver" seems to add an unconditional "From " line at the start > of each delivery. From sendmail, using the 'n' flag, "Mlocal F=...n..." > that is OK. (Although I'm not convinced that "dovecot.deliver", nor its > two-space separator (emphasis on "two") from the following date are > ideal. Nor, come to that line's lack of "@somewhere".) > > But from a procmail recipe, I end up with two "From " lines. Surely this > is incorrect. How can this be reduced to one? Shouldn't "deliver" ensure > that there is only "From " line? > > --- > Third: Would it be possible for "deliver" to do a "syslog" entry to > confirm final delivery into the destination mailbox, please? (I could try > and produce a patch, but someone else with more dovecot familiarity could > probably do the job must more quickly and probably also more cleanly!) > > > (I think that's all for the moment.) > > > > -- > > : David Lee I.T. Service : > : Senior Systems Programmer Computer Centre : > : Durham University : > : http://www.dur.ac.uk/t.d.lee/ South Road : > : Durham DH1 3LE : > : Phone: +44 191 334 2752 U.K. : >
On Tue, 3 Oct 2006, David Lee wrote:> [...] > Second: "deliver" seems to add an unconditional "From " line at the start > of each delivery. From sendmail, using the 'n' flag, "Mlocal F=...n..." > that is OK. (Although I'm not convinced that "dovecot.deliver", nor its > two-space separator (emphasis on "two") from the following date are > ideal. Nor, come to that, that line's lack of "@somewhere".) > > But from a procmail recipe, I end up with two "From " lines. Surely this > is incorrect. How can this be reduced to one? Shouldn't "deliver" ensure > that there is only "From " line? > [...]The deeper I look into this, the more convinced I am that there is a real problem in dovecot LDA, part of which is a misunderstanding by dovecot of the "mbox" "From " line and a consequent problem in code structure (not merely in code details). In what follows, I'll use the term "From_" (with a visible underscore) to refer to the "From " (word followed by a single space) which should actually be in the file. References to the code are based on rc7. The mbox format (check, for example, "mail.local" man pages) says that "mbox" delimits its messages by a prepended "From_" line at the start and an appended blank line at the end. (Dovecot does that.) But it is also clear that the next part of the "From_" line should be both a full email name "some.one at some.here", and also that this represents the sender. But dovecot's fixed text "dovecot.deliver" breaks both those. Naturally, I then turned to the source code, with a view to patching it. But this, I fear, seems to be much more convoluted than I had hoped. "deliver.c", near line 525, calls "create_mbox_stream()". This sets up the stream with the fixed "From dovecot.deliver ..." It then opens the mbox, returning result "box". Only then does it attempt to read the incoming email, which may itself already contain a "From_" specification. And that reading itself uses the "box" result which references the erroneous, prematurely-set, fixed string. What we need is something either: 1a Create the mbox stream, but without yet committing a "From_" spec. 1b Start reading the incoming email. If it already contains a "From_" spec., use that, else create some sort of default (equivalent to the exiting "dovecot.deliver" but as a full email name). 1c Put that "From_" into the mbox stream. 1d Copy remainder of incoming email (without any residual "From_") into the stream (etc.) or: 2a Read first line of incoming email. If it is a "From_", store it and also remove it from incoming stream, else create some sort of default "From_". (We now have a "From_" variable, and an incoming stream positioned after any leading "From_".) 2b Create mbox stream, very similarly to as at present, but using the "From_" variable. 2c Copy remainder of incoming email (without any residual "From_") into the stream (etc.) This is probably fixable by someone who knows the code. (But although I've got many years of C "under the belt", I'm new to the dovecot codebase, and this particular problem seems rather deeply embedded in the code's structure.) Any thoughts? Timo? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :