Dovecot installation problem (libssl_iostream_openssl.so is not portable!)
Hi there, i try to install dovecot from source with the following configuration: > ./configure --prefix=/test/core/dovecot --with-ssldir=/test/core/dovecot/tls the configuration runs fine with the following output at the end: > Install prefix . : /test/core/dovecot > File offsets ... : 64bit > I/O polling : epoll > I/O notifys : inotify > SSL : yes (OpenSSL) > GSSAPI . : no > passdbs : static passwd passwd-file shadow checkpassword > : -pam -bsdauth -ldap -sql > userdbs : static prefetch passwd passwd-file checkpassword > : -ldap -sql > CFLAGS . : -std=gnu99 -g -O2 -fstack-protector-strong > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -mfunction-return=keep > -mindirect-branch=keep -Wall -W -Wmissing-prototypes -Wmissing-declarations > -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast > -fno-builtin-strftime -Wstrict-aliasing=2 -I/test/dep/openssl/include > SYSTEMD : notify - /lib/systemd/system/dovecot.service > SQL drivers : > : -pgsql -mysql -sqlite -cassandra > Full text search : squat > : -lucene -solr But when i start to build (make) after a while i get the following error: > *** Warning: Linking the executable test-iostream-ssl against the loadable > module > *** libssl_iostream_openssl.so is not portable! > libtool: link: gcc -std=gnu99 -g -O2 -fstack-protector-strong > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -mfunction-return=keep > -mindirect-branch=keep -Wall -W -Wmissing-prototypes -Wmissing-declarations > -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast > -fno-builtin-strftime -Wstrict-aliasing=2 -I/test/dep/openssl/include -o > .libs/test-iostream-ssl test-iostream-ssl.o > ./.libs/libssl_iostream_openssl.so ./.libs/libssl_iostream.a > ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -L/test/dep/openssl/lib64 > -lssl -lcrypto -ldl -Wl,-rpath -Wl,/test/core/dovecot/lib/dovecot > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `ERR_free_strings' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `ENGINE_cleanup' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `SSL_library_init' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `OBJ_cleanup' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `CRYPTO_cleanup_all_ex_data' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `OpenSSL_add_all_algorithms' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `SSL_CTX_set_tmp_rsa_callback' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `EVP_cleanup' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `SSL_load_error_strings' > /usr/bin/ld: ./.libs/libssl_iostream_openssl.so: undefined reference to > `SSL_CTX_need_tmp_RSA' > collect2: error: ld returned 1 exit status > make[3]: *** [Makefile:655: test-iostream-ssl] Error 1 > make[3]: Leaving directory '/test/tmp/dovecot-2.3.17.1/src/lib-ssl-iostream' > make[2]: *** [Makefile:573: all-recursive] Error 1 > make[2]: Leaving directory '/test/tmp/dovecot-2.3.17.1/src' > make[1]: *** [Makefile:702: all-recursive] Error 1 > make[1]: Leaving directory '/test/tmp/dovecot-2.3.17.1' > make: *** [Makefile:546: all] Error 2 I've searched for the error and find some posts about set explicitly CPPFLAGS and LDFLAGS and something about missing shared libraries of openssl. My openssl have shared libraries (libcrypto.so libssl.so ...) and the explicit use of CPPFLAGS and LDFLAGS to my openssl hasn't changed anything I use Openssl 3.0 but i've tested also 1.1.1m and 1.1.1g for example, same error! Dovecot is the latest 2.3.17.1 My OS is Ubuntu 21.04 Can anyone help me with this please? Thanks!
Re: LMTP error on trying to find passwd-file for Postfix recipient validation
__ I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors. El 28/1/22 a les 12:50, Bernardo Reino ha escrit: On Fri, 28 Jan 2022, Narcis Garcia wrote: Hello everyone, I have following configurations (and more) at /etc/dovecot/local.conf in a "/VirtualUserFlatFilesPostfix/" setup : [partial file content begins] [snip] When incoming mail goes to a mailbox that does not exist, an error is logged by Dovecot, letter remains at Postfix queue, and no rejection message to sender (here host is /mail.example.net/): Wouldn't it make sense to prevent postfix from attempting to deliver (via LMTP) messages addressed to invalid users? i.e. using virtual_mailbox_maps and/or virtual_alias_maps, as needed. [partial]$ cat /var/log/dovecot.log 2022-01-28 08:52:00 lmtp(1883): Info: Connect from local 2022-01-28 08:52:00 auth: Error: passwd-file(wrongu...@example.net): stat(/srv/vmail/domains.d/example.net/users.d/wronguser/etc/passwd) failed: Address family not supported by protocol ^^^ weird message, but maybe it's dovecot's way of saying "file not found" :) My Postfix setup can't have all possible destination addresses registered because it does not only manage arrivals to local recipients but also does "domain relay" for some other FQDNs. Then I feel Postfix needs to pass next service (Either SASL-lmtp or next MTA hop) to result in a "deliverable or not deliverable action".
Re: Non-unique Message ID in mail messages
On January 27, 2022 6:17:05 AM AKST, "Daniel Ryšlink" wrote: > >RFC 5322 clearly states that mail messages SHOULD contain a Message ID >identifier, but if the do contain it, it MUST be globally unique. > That's nice polite behavior, all right, but the enforcement of it is another matter entirely. Slap a tracking label with a barcode on a piece of mail, and the mail truck is taking off from the loading dock at the post office with the door wide open being rear-ended by the cop car with a federal warrant and and a razor-sharp military letter opener in his hand. Oh yeah, I almost forgot I've got a flat tire and I discovered my brake hose was apparently slit wide open, and my att0rney says I'm facing additional charges since they had a lawful warrant to take all that action against me on my account. /sarcasm >Despite this requirement, I have encountered senders (namely Spamcop) >that sends obviously different (albeit related) messages called "Alert" >and "Summary" (they are always related to the same incident and have the >same Message ID). This creates all sorts of problems when processing >these mails, namely with users that have local forwards from one domain >to another (our mailserver hosts multiple domains), because for example >Dovecot refuses to forward the second message, flagging it as a duplicate. > >My question to you is - did you also encounter similar incorrect >(according to RFC standards) problem, and if so, is there a way to >persuade dovecot to perhaps determine the uniqueness of a message by >other means than just checking the message ID (i.e. look at other >identifiers, Subject, perhaps)? Because according to the log records, >Spamcop does not seem to be the only offender. > Thank you, that's a years-old bug, pet peeve and aggravation in several mailing systems not just Dovecot and you get my upvote for the question and complaint. We need to be nice, and deal respectfully but set our limits with people who aren't being so nice when they send emails. >Thanks in advance for any reactions, and if I did something wrong by >writing this message, I apologize again in advance. > >If required, I can provide samples of the Spamcop messages. > I am hoping there are more and better solutions to this problem forthcoming. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Non-unique Message ID in mail messages
On 27.01.22 16:17, Daniel Ryšlink wrote: RFC 5322 clearly states that mail messages SHOULD contain a Message ID identifier, but if the do contain it, it MUST be globally unique. The problem with that requirement being that it remains unclear how long the mail( copie)s it's attached to remain interchangeable versions of a "globally unique" message. When an e-mail sent to a...@b.com and c...@d.net gets split into two copies and the separate mailservers for b.com and d.net each forward a copy *as is* to e...@f.net, the f.net server would be entirely correct to call whichever arrives second a duplicate, even though they'll differ by at least the Received: headers. When c...@d.net is a (simplistic) mailinglist, however, AFAICT it is still considered proper that the copy it sends to e...@f.net retains the original Message-ID - even though there will be more extensive changes to the headers (list headers, Reply-To:, possibly stuff like retrofitting SPF and DKIM, ...). Assuming that the list mail arrives second at f.net, deduplication will keep the recipient from ever reaping the benefit of those changed headers (as in, having a "Reply List" button pop up in TB). (However, if I understand correctly that on the list you're talking about you see the same Message-ID applied to e-mails that are essentially *replies*/followups to the original one with entirely different content, I suppose that most people will agree that they *should* each have a Message-ID of their own, with the IDs of the earlier e-mails appearing in In-Reply-To: and References: headers to support threading in MUAs.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature
Re: LMTP error on trying to find passwd-file for Postfix recipient validation
On Fri, 28 Jan 2022, Narcis Garcia wrote: Hello everyone, I have following configurations (and more) at /etc/dovecot/local.conf in a "/VirtualUserFlatFilesPostfix/" setup : [partial file content begins] [snip] When incoming mail goes to a mailbox that does not exist, an error is logged by Dovecot, letter remains at Postfix queue, and no rejection message to sender (here host is /mail.example.net/): Wouldn't it make sense to prevent postfix from attempting to deliver (via LMTP) messages addressed to invalid users? i.e. using virtual_mailbox_maps and/or virtual_alias_maps, as needed. [partial]$ cat /var/log/dovecot.log 2022-01-28 08:52:00 lmtp(1883): Info: Connect from local 2022-01-28 08:52:00 auth: Error: passwd-file(wrongu...@example.net): stat(/srv/vmail/domains.d/example.net/users.d/wronguser/etc/passwd) failed: Address family not supported by protocol ^^^ weird message, but maybe it's dovecot's way of saying "file not found" :) Good luck.
Re: can't authenticate
Hello Am 27.01.22 um 17:37 schrieb David Matthews: > hi Christian > >> Did the password hash algorithm change between devuan 3 and 4? You >> can check that in your /etc/shadow file. > > As I understand, devuan is pretty much debian without systemd? And > that if you were prepared to do a fair bit of work you could start > with debian installed, hack it about and end up with something like > devuan? > > I doubt devuan has done anything to deviate from debian at this level > and both machines were recently dist-upgraded. Dovecot needed no > tinkering with at all on the debian machine. > I never used devuan, so I can not comment on its upgrade strategies. The default in Debian has changed, but on an dist-upgrade they are not changed automatically. This would not be possible anyway, as you need the original password for generating the new hash. But you could enforce the user to change it on the next login. The hash algorithm changes, when you set a new or other password. Check also release notes of Bulseye: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#pam-default-password >> The start of the password field should be the same something like >> $6$... >> > > Yes it is on devuan 4. I no longer have anything with devuan 3 to > check that, but it shouldn't have changed in a dist-upgrade? > Interestingly, although it's the same user and password on both > machines, I notice that the hashes in /etc/shadow are not identical > after the commencing $6$. But then I don't know how these hashes are > derived, so maybe that is not unexpected? > So the password algorithm didn't change. $6$ is still the old one SHA-512. The hashes are different between machines, as they are salted. The salt is stored after $6$ up till the next $ sign. As the salt differs, the hash has to be different. Thats what salts are made for :-) So you only can increase the logging in dovecot for authentication to debugging. auth_debug=yes Perhaps you also want to set auth_debug_passwords=yes for getting the actual password in plain text. (Don't forget to disable that afterwards!) Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature
RE: Non-unique Message ID in mail messages
> I apologize for bringing perhaps trivial/well-known matter, but I am > interested in your opinion. > > RFC 5322 clearly states that mail messages SHOULD contain a Message ID > identifier, but if the do contain it, it MUST be globally unique. > > Despite this requirement, I have encountered senders (namely Spamcop) > that sends obviously different (albeit related) messages called "Alert" > and "Summary" (they are always related to the same incident and have the > same Message ID). This creates all sorts of problems when processing > these mails, namely with users that have local forwards from one domain > to another (our mailserver hosts multiple domains), because for example > Dovecot refuses to forward the second message, flagging it as a duplicate. > > My question to you is - did you also encounter similar incorrect > (according to RFC standards) problem, and if so, is there a way to > persuade dovecot to perhaps determine the uniqueness of a message by > other means than just checking the message ID (i.e. look at other > identifiers, Subject, perhaps)? Because according to the log records, > Spamcop does not seem to be the only offender. > I would think this is more related to MTA's then dovecot. It is dovecot's core job to put messages in mailboxes. However interesting this globally unique. At first sight, I would say a bit unnecessarily broad. I would recommend using a mail filter in any mta, grab whatever you want and analyze that, with that solution you can add any header you like. I do not get what spamcop has to do with this, afaik this is a dnsbl.
LMTP error on trying to find passwd-file for Postfix recipient validation
Hello everyone,
I have following configurations (and more) at /etc/dovecot/local.conf in
a "/VirtualUserFlatFilesPostfix/" setup :
[partial file content begins]
protocols = imap pop3 lmtp sieve
mail_location = maildir:~/data:INBOX=~/data/.INBOX
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
user = vmail
group = vmail
mode = 0660
}
}
protocol lmtp {
postmaster_address = postmas...@example.net
mail_plugins = $mail_plugins sieve
}
userdb {
driver = passwd-file
args = username_format=%u /srv/vmail/domains.d/%d/users.d/%n/etc/passwd
}
passdb {
driver = passwd-file
args = username_format=%u
/srv/vmail/domains.d/%d/users.d/%n/etc/shadow.%Ls
}
service auth {
unix_listener /var/spool/postfix/private/auth {
user = postfix
group = postfix
mode = 0660
}
}
[/partial file content ends]
Everyting works (IMAP mail is stored, IMAP/POP3 mail is retrieved,
incoming SMTP mail from Postfix is delivered, Outgoing SMTP senders are
authenticated from Postfix~SASL) BUT:
When incoming mail goes to a mailbox that does not exist, an error is
logged by Dovecot, letter remains at Postfix queue, and no rejection
message to sender (here host is /mail.example.net/):
[partial]$ cat /var/log/mail.log
2022-01-28T08:52:00.851751+01:00 correo postfix/smtpd[1853]:
CFDA63A174B: client=mail.example.com[1.2.3.4]
2022-01-28T08:52:00.872248+01:00 correo postfix/cleanup[1881]:
CFDA63A174B: message-id=<83c79ee1-6e2e-4e15-307e-17cdc7e2b...@example.com>
2022-01-28T08:52:00.884100+01:00 correo postfix/qmgr[1529]: CFDA63A174B:
from=, size=854, nrcpt=1 (queue active)
2022-01-28T08:52:00.884507+01:00 correo postfix/smtpd[1853]: disconnect
from mail.example.com[1.2.3.4] ehlo=2 starttls=1 mail=1 rcpt=1 data=1
quit=1 commands=7
2022-01-28T08:52:00.969275+01:00 correo postfix/lmtp[1882]: CFDA63A174B:
to=,
relay=mail.example.net[private/dovecot-lmtp], delay=0.43,
delays=0.35/0.02/0.02/0.05, dsn=4.3.0, status=deferred (host
mail.example.net[private/dovecot-lmtp] said: 451 4.3.0
Temporary internal error (in reply to RCPT TO
command))
[partial]$ cat /var/log/dovecot.log
2022-01-28 08:52:00 lmtp(1883): Info: Connect from local
2022-01-28 08:52:00 auth: Error: passwd-file(wrongu...@example.net):
stat(/srv/vmail/domains.d/example.net/users.d/wronguser/etc/passwd)
failed: Address family not supported by protocol
2022-01-28 08:52:00
lmtp(wrongu...@example.net)<1883>: Error: user
wrongu...@example.net: Auth USER lookup failed
2022-01-28 08:52:00 lmtp(1883): Error: Failed to lookup user
wrongu...@example.net: Internal error occurred. Refer to server log for
more information.
2022-01-28 08:52:00 lmtp(1883): Info: Disconnect from local: Client has
quit the connection (state=READY)
Thank you for any help in debugging configuration or suggestion to
enhance Postfix/Dovecot parameters.
Postfix 3.4
Dovecot 2.3
--
Narcis Garcia
__
I'm using this dedicated address because personal addresses aren't masked
enough at this mail public archive. Public archive administrator should fix
this against automated addresses collectors.
Errors: Failed to map transaction log, Corrupted transaction log, imeout (180s) while waiting for lock for transaction log
Hi, no, it is a single mail server, no replication at all. Thank you > Hello > > We only saw such errors with replication between two machines, when new > emails where errornously deliverd to both of them or clients connected > to both simultaniously. > > Do you have such a setup? > Kind regards, > Christian Mack
