On Jul 17, 2012, at 3:18 AM, Charles Marcus wrote: >> I really thought it would be a simple "here's what you missed", since >> the logs are relatively uninformative... > > The point is, what may appear to be uninformative to you may tell Timo (or > someone else who knows what to look for) all they need to know to pinpoint > the problem.
Whilst I would normally agree, at the same time I've had a fair amount of experience with dovecot and sendmail (been running them for over 10 years). Pigeonhole is new to me, however. . . > One thing I did notice is that you are sending this mail from an internal > IP... since most people use very different checks for such mail (bypassing > many/most checks), maybe you should be testing from an external address (one > that comes in from outside your network)? So I have a DMZ that houses the mail server for my domain, which is where the private addresses are. Connections are passed through the OpenBSD router to the mail server. So testing from an external address would be essentially the same (since the connection to the SMTP server talks to the sendmail process as the /usr/lib/sendmail process). Regardless, my original tests were sending mail from the Mac off-network. > Also, it is always recommended when setting up a new server to start with the > latest version... for 2.0.x that would be 2.0.19, but the latest is 2.1.8... When I set it up, 2.0.13 _was_ the latest. :-) I was hoping to avoid the pain of recompiling dovecot and pigeonhole. Not that big a deal, I guess. . . >> lda_original_recipient_header = X-Original-To >> lmtp_save_to_detail_mailbox = yes > > Ok, I think this is the problem... > > Dovecot's LMTP currently does NOT preserve the x-original-to header... in > fact, brought this up recently (I was one of the ones interested in Timo > adding support for it) on this (and the postfix, which is what I use) on this > very list: > > http://www.dovecot.org/list/dovecot/2012-April/065075.html > > Apparently, after Timo discussed this on the postfix list, he determined that > it would not be a very significant change for him to make to add support for > this header in LMTP and that he would get to it sooner than later, but as of > now, it has not been added. Actually, I'm not using lmtp. I whacked the lmtp_save_to_detail_mailbox in an effort to see if that was the issue before I realized I don't have it turned on. dovecot.conf has: protocols = imap though in 20-managesieve.conf I have: protocols = $protocols sieve I just turned it off and restarted dovecot (though lmtp was not running) and re-ran the test with the same result. So, I think what's going on is pretty straightforward. The local mailer definition in the sendmail.cf file is: Mlocal, P=/usr/local/libexec/dovecot/dovecot-lda, F=lsDFMAw5:/|@qSPhn9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/X-Unix, A=/usr/local/libexec/dovecot/dovecot-lda -d $u This is more or less right out of the wiki. Since dovecot-lda is passed the -d option, it's using that (and only that) for delivery. Since there's no X-Original-To: header, it doesn't really have any option (since the non-envelope-to address might not exist, or point to something other than the end user's mailbox, etc). It would appear that I have two options: 1) Figure out what macro(s) is(are) valid to pass to dovecot-lda with the -a option in the sendmail config file (sendmail.cf). 2) Get sendmail to put "X-Original-To: <address>" in the header. Both would appear to be a sendmail issue, not a dovecot/pigeonhole issue. Everything I find on the web seems to center around how to use plus addressing to accept mail from multiple email address and filter it into a single address for delivery, only to have the local delivery agent break it back out again. That's not my issue. :-( Sean Sean
