On Mon, 2011-09-19 at 23:22 -0400, Phil Pennock wrote:
> On 2011-09-19 at 17:32 -0700, Ross Boylan wrote:
> > I am getting non-spam emails that fail delivery over LMTP to Cyrus IMAP.
> > Most likely the cause is lines that are too long (though it could also
> > be embedded NULLs).
> >
> > I would appreciate suggestions about how to handle this, assuming I'm
> > stuck with Cyrus's behavior.*
>
> Cyrus imapd.conf:
> reject8bit: no
> munge8bit: no
>
> Those should be sufficient.
Those options don't look as if they affect the long-line handling (or
really, even NUL, since its 8th bit is 0). Am I missing something?
Also my config file has the comment
# spamware. If you kept reject8bit disabled, you can choose to leave the
# crappage untouched by disabling this (if you don't care that IMAP SEARCH
# won't work right anymore.
#munge8bit: no
which doesn't sound too good, as I'd like SEARCH to work:)
Thanks for the tips.
Ross
>
> Other advice on integration:
>
> If you're using +addressing with Exim's:
> local_part_suffix = +*
> local_part_suffix_optional
> then put "rcpt_include_affixes" on the LMTP-invoking Transport (whether
> smtp or lmtp driver) to pass the +address on to Cyrus; then the
> "imapmagicplus: yes" imapd.conf setting will let you grant "anyone" the
> "p" permission on "foobar" (as a child of INBOX) and you can have
> auto-delivery into that folder for mail going to you+foobar.
>
> I actually use these options on the Transport, besides driver & socket:
>
> envelope_to_add
> user = cyrus
> group = cyrus
> rcpt_include_affixes
> headers_remove = "lines"
> headers_add = "Lines: $body_linecount"
>
> The Lines: header makes mutt's index view able to show how large a mail
> is without first needing to retrieve the body.
>
> (And, personally, I tell cyrus to use "skiplist" or "flat" for all DB
> types, because I got fed up with debugging yet more bdb
> self-incompatibilities with upgrades and whether or not db_upgrade
> would actually work).
>
> -Phil
