[prev in list] [next in list] [prev in thread] [next in thread] 

List:       exim-users
Subject:    Re: [exim] dealing with LMTP errors
From:       John Jetmore <jj33 () pobox ! com>
Date:       2011-09-20 12:41:33
Message-ID: CAKFJo=rAAtTsnkcjaj8MULQB+1c58WhsXWEy9aN6wT-L2f_Hew () mail ! gmail ! com
[Download RAW message or body]

On Mon, Sep 19, 2011 at 8:32 PM, Ross Boylan <ross@biostat.ucsf.edu> 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).
>
> ...
>
> A cruder approach would be to reset the the enveloper sender to a
> special address on my system, and have mail to that address delivered to
> a regular mailbox in my home directory.  It would also be good to have a
> notification sent to me so I know this is going on; I guess I could do
> that with a second router for the special bounce address that used a
> pipe to send the alert.
>
> Any thoughts?

I don't know anything about the Cyrus side, but I once had a similar
issue with getting Exim to speak to an Oracle Collaboration Suite
installation.  OCS had a hard line-limit, and when it was reached it
would terminate the SMTP session.  This left the mail in my queue and
essentially DOSed my server until the retry expired.  After Oracle
proved worthless at even acknowledging the issue existed, I put the
following router/transport combo in place:

# this router goes right before delivery attempts to OCS.  If we are getting
# ready to deliver to OCS, check to see if the message has a long line and
# sideline it if necessary.
ocs_sideline_longline:
  driver = accept
  transport = ocs_sideline
  verify = false
  condition = ${if >{$max_received_linelength}{8000}{yes}{no}}

# this is the transport that saves long-line emails for later review
ocs_sideline:
  driver = appendfile
  check_string = ""
  directory = /wcs/exim/spool/ocs_sideline/
  message_prefix = ""
  message_suffix = ""
  mode = 0600
  use_bsmtp
  batch_max = 100

This would save a bsmtp format file to disk, allowing me to review it.
 It was almost always trash (I seem to remember that Dell
advertisements often had HTML that consisted of a single very long
line).  If it was trash I could just delete the file, if it was worth
keeping I could edit the file by hand and then re-deliver using exim
-bS.

As for notifications, we already had a logfile watcher on the exim
logs, so it was just a matter of writing a new pattern for
T=ocs_sideline.

I assume NULLs could be caught the same way.  This isn't the most
elegant solution, but it was very fast to implement, and only needed
human attention every two weeks or so.

Hope that helps
--John

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[prev in list] [next in list] [prev in thread] [next in thread]