Header DATE field not returned when placed after MIME section
Hello, I am using Dovecot 2.2.34p0 on OpenBSD 6.3 stable. I am writting an application using the vmime (http://www.vmime.org) library (x-ref issue: https://github.com/kisli/vmime/issues/199). I noticed through testing over my own e-mail server that in some situations the DATE field is not returned upon ENVELOPE or HEADER.FIELDS request. The e-mails at fault happen to have the DATE field at the very end of the header, after the MIME section. Example 1: Delivered-To: Received: Return-Path: Delivered-To: DKIM-Signature: From: To: Message-ID: Subject: MIME-Version: 1.0 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Fri, 01 Jun 2018 17:44:44 -0400 Example 2: Return-Path: Delivered-To: Received: Delivered-To: DKIM-Signature: From: Reply-To: To: Subject: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_Part_338_1573405959.1527768044781" X-Mailer: EMail_2.0 Date: Fri, 01 Jun 2018 17:36:01 -0400 Thanks in advance for the insight,
Re: Dovecot LDA errors
Ok thanks Larry, I'll have a look at LTMP on Monday and give you a shout if I want to see your configs, thanks a lot for the reply, Andy.
Re: Dovecot LDA errors
I moved from the LDA to LMTP and a lot of “weird” things stopped. Let me know if you’d like to see my exim setup. (I’m also on FreeBSD, and the Dovecot maintainer and committer). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larry...@gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 From: dovecot on behalf of Andy Smith Date: Friday, June 1, 2018 at 11:40 AM To: Dovecot List Subject: Dovecot LDA errors Hi list, I'm having an issue on a server thats been running ok for years, its running Exim 4.91 onto of FreeBSD 10.4 with Dovecot 2.3.1. Recently I've started seeing messages getting stuck in the queue for local delivery and upon checking the Exim log I see this: 2018-06-01 17:31:09.339 [48228] 1fOmxJ-000CXp-3s : dovecot_delivery transport output: lda(a.smith): Fatal: Invalid -f parameter: Path is empty string 2018-06-01 17:31:09.339 [48228] 1fOmxJ-000CXp-3s == a.sm...@ldexgroup.co.uk R=virtual_localuser T=dovecot_delivery defer (0): Child process of dovecot_delivery transport returned 64 (could mean usage or syntax error) from command: /usr/local/libexec/dovecot/dovecot-lda I'm using this line for the LDA in my exim config: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f "$s ender_address" -a $original_local_part@$original_domain I haven't changed any of the config, but I have updated both Exim and Dovecot. So obviously the reason seems to be that $sender_address is null, the obvious place to look I suppose is Exim but I'm seeing this particularly for things like sieve out of office, which are generated by the LDA itself and then give this error when trying to deliver the out of office message to a local user. I'll post a question also to the Exim forum, but wondered if this problem rings any bells for anyone on here? thanks in advance! Andy.
Dovecot LDA errors
Hi list, I'm having an issue on a server thats been running ok for years, its running Exim 4.91 onto of FreeBSD 10.4 with Dovecot 2.3.1. Recently I've started seeing messages getting stuck in the queue for local delivery and upon checking the Exim log I see this: 2018-06-01 17:31:09.339 [48228] 1fOmxJ-000CXp-3s : dovecot_delivery transport output: lda(a.smith): Fatal: Invalid -f parameter: Path is empty string 2018-06-01 17:31:09.339 [48228] 1fOmxJ-000CXp-3s == a.sm...@ldexgroup.co.uk R=virtual_localuser T=dovecot_delivery defer (0): Child process of dovecot_delivery transport returned 64 (could mean usage or syntax error) from command: /usr/local/libexec/dovecot/dovecot-lda I'm using this line for the LDA in my exim config: command = /usr/local/libexec/dovecot/dovecot-lda -d $local_part@$domain -f "$s ender_address" -a $original_local_part@$original_domain I haven't changed any of the config, but I have updated both Exim and Dovecot. So obviously the reason seems to be that $sender_address is null, the obvious place to look I suppose is Exim but I'm seeing this particularly for things like sieve out of office, which are generated by the LDA itself and then give this error when trying to deliver the out of office message to a local user. I'll post a question also to the Exim forum, but wondered if this problem rings any bells for anyone on here? thanks in advance! Andy.
Re: SSL error after upgrading to 2.31
On 05/30/18 10:41, A. Schulze wrote: In the third case an administrator has to provide files with certificates. And these files are required (by best practice) Do you have any pointers to support such a strong statement? to include any chain-certificates excluding the self signed root. Our upstream CA surely does not ship the signed certs that way. It could, and that would support your statement - but it doesn't. There is no reason to only provide a certificate via ssl_cert = and an new/other place to provide intermediates. Yes, there is. It saves manipulating the signed server cert, and mirrors the fact that the intermediate CA certs have a longer lifetime than the server cert. Cheerio, hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
GSSAPI vs group check
Dear All,
Is it possible to make any authorization (eg. checking of group
membership) in case of GSSAPI authentication?
Our dovecot authenticates the users against PAM and GSSAPI. In the PAM
file I'm able to check if a user is a member of a selected (e.g
mailreader) group. If the user is member, he can login otherwise not
(see below). If the user has a valid Kerberos ticket and he tries to
login via GSSAPI, I can't restrict him if he is not a member of the
selected group.
How can I overcome this issue?
My config:
passdb {
driver = pam
# [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=]
# [cache_key=] []
#args = dovecot
}
userdb {
#
driver = passwd
# [blocking=no]
#args =
# Override fields from passwd
#override_fields = home=/home/virtual/%u
}
...in PAM file:
auth [success=1 default=ignore] pam_succeed_if.so user ingroup
mailreader
auth [success=ignore default=2] pam_succeed_if.so user ingroup
admins
auth [success=ignore default=1] pam_succeed_if.so uid >= 1000
auth [success=3 default=ignore] pam_winbind.so krb5_auth
krb5_ccache_type=FILE cached_login
auth [success=ignore default=1] pam_succeed_if.so uid < 1000
auth [success=1 default=ignore] pam_unix.so nullok_secure
try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
Thank you.
Br,
Ákos
Re: 2.3.1 Replication is throwing scary errors
On 1/06/2018 2:47 AM, Michael Grimm wrote: On 31. May 2018, at 18:09, Remko Lodder wrote: On 31 May 2018, at 17:52, Michael Grimm wrote: I would love to get some feedback from the developers regarding: #) are commercial customers of yours running 2.3 master-master replication without those issues reported in this thread? #) do you get reports about these issues outside this ML as well? #) and ... What sort of debugging, short of bisecting 100+ patches between the commits above, can we do to progress this? … what kind of debugging do you suggest? Aki sent me over some patches recently and I have build a custom package for it for FreeBSD. It’s in my pkg repo which I can forward you if you want it. Great news. I'd love to test it, thus, could you forward it to me? Thanks. Very good news. I too would love to test and am more than happy to share config, system setup and logs . Please forward the the pkg repo if you wouldn't mind. You need to add some lines to the logging thing and then trace those and collaborate with the dovecot community/developers. And, please let me know, which config is needed for those logging lines as well. As above please I did not have yet found the time to actively persue this due to other things on my head. Sorry for that. I hope to do this “soon” but I dont want to pin myself to a commitment that I might not be able to make :) Well, I will give it a try. But: more testers might see more in those logging lines ;-) Regards, Michael More than willing to test. Regards, Andy
