Re: submission configuration issues
service submission-login {
inet_listener submissions {
haproxy = no
port = 465
reuse_port = no
ssl = yes
}
}
Shouldn't the port be 587 here?
My config file looks like:
service submission-login {
inet_listener submission {
#port = 587
}
}
The # comment must also mean something..
On 7/27/19 3:21 PM, Jean-Daniel via dovecot wrote:
Le 27 juil. 2019 à 14:30, Stephan Bosch > a écrit :
On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
Hello,
I'm having trouble configuring the submission proxy.
I have configured the submission service as follow:
submission_host = smtp.example.com
submission_relay_host = localhost
submission_relay_port = 8587
Le 27 juil. 2019 à 14:30, Stephan Bosch > a écrit :
On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote:
Hello,
I'm having trouble configuring the submission proxy.
I have configured the submission service as follow:
submission_host = smtp.example.com
submission_relay_host = localhost
submission_relay_port = 8587
submission_relay_rawlog_dir = /var/log/dovecot/
submission_relay_trusted = yes
My main issue is that until I login, dovecot-submission won't
connect to the backend and query the capabilities and so won't
report the right capabilities.
That mean that the first EHLO message don't get the right
capabilities list.
"
EHLO example.com
250-smtp.example.com
250-8BITMIME
250-AUTH PLAIN LOGIN
250-BURL imap
250-CHUNKING
250-ENHANCEDSTATUSCODES
250-SIZE
250 PIPELINING
"
This list don't contains VRFY, DNS, and SIZE is not specified (all
of these is present in backend EHLO response).
After login, if I send an new EHLO command, everything is properly
reported. The raw log shows that unlike what the documentation says,
dovecot don't try to connect to the backend until the user is
properly logged.
In my raw log I show that after I logged in dovecot-submission, the
later open a connection to the backend and send a X-CLIENT command.
Now, if I try to force the capabilities by using:
submission_backend_capabilities = VRFY 8BITMIME DSN
dovecot properly reports all SMTP capabilities in the first EHLO
response, but it completely stops emitting X-CLIENT command to the
backend
and try to simply forward the command without authentication, which
result in postfix rejecting the command with an unauthorized user error.
What is wrong with my configuration ?
Thanks.
Can you send us your complete configuration (output from `dovecot -n`)?
Yes (see below).
Some additional information:
===
When I connect directly to dovecot-submission using nc and send an
EHLO command, I got the following result (the SIZE is configured in
dovecot config, that’s why it is properly announced), but no raw_log
are generated at all.
$ nc smtp.example.com 587
220 smtp.example.com Dovecot ready.
EHLO mydomain.com
250-smtp.example.com
250-8BITMIME
250-AUTH
250-BURL imap
250-CHUNKING
250-ENHANCEDSTATUSCODES
250-SIZE 41943040
250-STARTTLS
250 PIPELINING
QUIT
221 2.0.0 Bye
===
Ditto if I use openssl s_client -starttls smtp -crlf -connect
smtp.example.com:587 and send the EHLO
after STARTTLS.
===
For the record, here is the result of a direct connect to postfix:
$ nc 127.0.0.1 8587
220 smtp.example.com ESMTP Postfix
EHLO example.com
250-smtp.example.com
250-PIPELINING
250-SIZE 41943040
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN DESTADDR DESTPORT
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
===
And here is the content of the row logs when a mail is sent.
rawlog.in
1564258521.813430 220 smtp.example.com ESMTP
Postfix
1564258521.814206 250-smtp.example.com
1564258521.814206 250-PIPELINING
1564258521.814206 250-SIZE 41943040
1564258521.814206 250-VRFY
1564258521.814206 250-ETRN
1564258521.814206 250-STARTTLS
1564258521.814206 250-AUTH PLAIN LOGIN
1564258521.814206 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT
LOGIN DESTADDR DESTPORT
1564258521.814206 250-ENHANCEDSTATUSCODES
1564258521.814206 250-8BITMIME
1564258521.814206 250-DSN
1564258521.814206 250 SMTPUTF8
1564258521.848159 220 smtp.example.com ESMTP
Postfix
1564258521.849506 250-smtp.example.com
1564258521.849506 250-PIPELINING
1564258521.849506 250-SIZE 41943040
1564258521.849506 250-VRFY
1564258521.849506 250-ETRN
1564258521.849506 250-STARTTLS
1564258521.849506 250-AUTH PLAIN LOGIN
1564258521.849506 250-XCLIENT NAME ADDR
Re: submission configuration issues
> Le 27 juil. 2019 à 23:13, Stephan Bosch a écrit : > > > > On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote: >> Hello, >> >> I'm having trouble configuring the submission proxy. >> >> I have configured the submission service as follow: >> >> submission_host = smtp.example.com >> submission_relay_host = localhost >> submission_relay_port = 8587 >> submission_relay_rawlog_dir = /var/log/dovecot/ >> submission_relay_trusted = yes >> >> My main issue is that until I login, dovecot-submission won't connect to the >> backend and query the capabilities and so won't report the right >> capabilities. > > That is true and expected. No connection to the relay server is made until > the user is logged in. > >> That mean that the first EHLO message don't get the right capabilities list. >> >> " >> EHLO example.com >> >> 250-smtp.example.com >> 250-8BITMIME >> 250-AUTH PLAIN LOGIN >> 250-BURL imap >> 250-CHUNKING >> 250-ENHANCEDSTATUSCODES >> 250-SIZE >> 250 PIPELINING >> " >> >> This list don't contains VRFY, DNS, and SIZE is not specified (all of these >> is present in backend EHLO response). >> After login, if I send an new EHLO command, everything is properly reported. >> The raw log shows that unlike what the documentation says, >> dovecot don't try to connect to the backend until the user is properly >> logged. > Oh, then we need to adjust the documentation. This is normal behavior. This is in the default 20-submission.conf file: # By default, the submission service first connects to the relay server to # determine the support for such capabilities before sending the initial EHLO # reply to the client. If the list of capabilities returned by the relay server # is somehow unreliable or it is undesirable to start the connection to the # relay server before the first mail transaction is started, the backend # capabilities can be configured explicitly using the # submission_backend_capabilities setting. … #submission_backend_capabilities =
Re: submission configuration issues
On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote: Hello, I'm having trouble configuring the submission proxy. I have configured the submission service as follow: submission_host = smtp.example.com submission_relay_host = localhost submission_relay_port = 8587 submission_relay_rawlog_dir = /var/log/dovecot/ submission_relay_trusted = yes My main issue is that until I login, dovecot-submission won't connect to the backend and query the capabilities and so won't report the right capabilities. That is true and expected. No connection to the relay server is made until the user is logged in. That mean that the first EHLO message don't get the right capabilities list. " EHLO example.com 250-smtp.example.com 250-8BITMIME 250-AUTH PLAIN LOGIN 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 250 PIPELINING " This list don't contains VRFY, DNS, and SIZE is not specified (all of these is present in backend EHLO response). After login, if I send an new EHLO command, everything is properly reported. The raw log shows that unlike what the documentation says, dovecot don't try to connect to the backend until the user is properly logged. Oh, then we need to adjust the documentation. This is normal behavior. In my raw log I show that after I logged in dovecot-submission, the later open a connection to the backend and send a X-CLIENT command. Now, if I try to force the capabilities by using: submission_backend_capabilities = VRFY 8BITMIME DSN dovecot properly reports all SMTP capabilities in the first EHLO response, but it completely stops emitting X-CLIENT command to the backend and try to simply forward the command without authentication, which result in postfix rejecting the command with an unauthorized user error. Yes, that is a bug. I have reproduced it here. We will look into it. Regards, Stephan.
Re: submission configuration issues
> Le 27 juil. 2019 à 14:30, Stephan Bosch a écrit : > > On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote: >> Hello, >> >> I'm having trouble configuring the submission proxy. >> >> I have configured the submission service as follow: >> >> submission_host = smtp.example.com >> submission_relay_host = localhost >> submission_relay_port = 8587 > Le 27 juil. 2019 à 14:30, Stephan Bosch a écrit : > > On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote: >> Hello, >> >> I'm having trouble configuring the submission proxy. >> >> I have configured the submission service as follow: >> >> submission_host = smtp.example.com >> submission_relay_host = localhost >> submission_relay_port = 8587 >> submission_relay_rawlog_dir = /var/log/dovecot/ >> submission_relay_trusted = yes >> >> My main issue is that until I login, dovecot-submission won't connect to the >> backend and query the capabilities and so won't report the right >> capabilities. >> >> That mean that the first EHLO message don't get the right capabilities list. >> >> " >> EHLO example.com >> >> 250-smtp.example.com >> 250-8BITMIME >> 250-AUTH PLAIN LOGIN >> 250-BURL imap >> 250-CHUNKING >> 250-ENHANCEDSTATUSCODES >> 250-SIZE >> 250 PIPELINING >> " >> >> This list don't contains VRFY, DNS, and SIZE is not specified (all of these >> is present in backend EHLO response). >> After login, if I send an new EHLO command, everything is properly reported. >> The raw log shows that unlike what the documentation says, >> dovecot don't try to connect to the backend until the user is properly >> logged. >> >> In my raw log I show that after I logged in dovecot-submission, the later >> open a connection to the backend and send a X-CLIENT command. >> >> >> Now, if I try to force the capabilities by using: >> >> submission_backend_capabilities = VRFY 8BITMIME DSN >> >> dovecot properly reports all SMTP capabilities in the first EHLO response, >> but it completely stops emitting X-CLIENT command to the backend >> and try to simply forward the command without authentication, which result >> in postfix rejecting the command with an unauthorized user error. >> >> What is wrong with my configuration ? >> Thanks. > > Can you send us your complete configuration (output from `dovecot -n`)? Yes (see below). Some additional information: === When I connect directly to dovecot-submission using nc and send an EHLO command, I got the following result (the SIZE is configured in dovecot config, that’s why it is properly announced), but no raw_log are generated at all. $ nc smtp.example.com 587 220 smtp.example.com Dovecot ready. EHLO mydomain.com 250-smtp.example.com 250-8BITMIME 250-AUTH 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 41943040 250-STARTTLS 250 PIPELINING QUIT 221 2.0.0 Bye === Ditto if I use openssl s_client -starttls smtp -crlf -connect smtp.example.com:587 and send the EHLO after STARTTLS. === For the record, here is the result of a direct connect to postfix: $ nc 127.0.0.1 8587 220 smtp.example.com ESMTP Postfix EHLO example.com 250-smtp.example.com 250-PIPELINING 250-SIZE 41943040 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN DESTADDR DESTPORT 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 === And here is the content of the row logs when a mail is sent. rawlog.in 1564258521.813430 220 smtp.example.com ESMTP Postfix 1564258521.814206 250-smtp.example.com 1564258521.814206 250-PIPELINING 1564258521.814206 250-SIZE 41943040 1564258521.814206 250-VRFY 1564258521.814206 250-ETRN 1564258521.814206 250-STARTTLS 1564258521.814206 250-AUTH PLAIN LOGIN 1564258521.814206 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN DESTADDR DESTPORT 1564258521.814206 250-ENHANCEDSTATUSCODES 1564258521.814206 250-8BITMIME 1564258521.814206 250-DSN 1564258521.814206 250 SMTPUTF8 1564258521.848159 220 smtp.example.com ESMTP Postfix 1564258521.849506 250-smtp.example.com 1564258521.849506 250-PIPELINING 1564258521.849506 250-SIZE 41943040 1564258521.849506 250-VRFY 1564258521.849506 250-ETRN 1564258521.849506 250-STARTTLS 1564258521.849506 250-AUTH PLAIN LOGIN 1564258521.849506 250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN DESTADDR DESTPORT 1564258521.849506 250-ENHANCEDSTATUSCODES 1564258521.849506 250-8BITMIME 1564258521.849506 250-DSN 1564258521.849506 250 SMTPUTF8 1564258521.854093 250 2.1.0 Ok 1564258521.909487 250 2.1.5 Ok 1564258521.983093 354 End data with . 1564258522.115312 250 2.0.0 Ok: queued as DDBCCD53B rawlog.out 1564258521.813739 EHLO smtp.example.com 1564258521.846054 XCLIENT HELO=[10.188.153.106] PROTO=ESMTP LOGIN=info PORT=47564 ADDR=46.193.33.66 1564258521.848701 EHLO smtp.example.com 1564258521.850122 MAIL FROM: AUTH=info 1564258521.889896 RCPT TO: 1564258521.981094 DATA 1564258521.983757 Received: from [10.188.153.106] ([46.193.33.66])
Re: Since multiple ,matches
Never mind, I figured out my (stupid) error.
> I have a rule in sieve like the following:
>
> if anyof (header :contains ["to"] [ "box", "change", "cornell”, “twitter”]) {
--
'My strength is like the strength of ten because my heart is pure,' said
Carrot. 'Really? Well, there's eleven of them.' —Jingo
Since multiple ,matches
I have a rule in sieve like the following:
if anyof (header :contains ["to"] [ "box", "change", "cornell”, “twitter”]) {
setflag "\\Seen";
fileinto :create "misc";
stop;
}
The messages that come in are using address extensions, so
user+twit...@example.com, for example.
The trouble is, this sieve recipe doesn’t get triggered and the message gets
filed into the extension folder “twitter” or “cornell” instead of “misc”.
I have a very similar recipe following that one:
if header :contains "to" "root" {
setflag "\\Seen";
addflag "$label5";
fileinto :create "root";
stop;
}
And that one works as I expect.
Is that multiple match format valid for :contains (I’ve only seen it used for
:regex)? I don’t get an error.
Is there a way to run a debug log for the sieve recipe? Preferably for a single
user.
--
Vernon: Now this is the thought that wakes me up in the middle of the
night. That when I get older, these kids are going to take care of me
Carl: I wouldn't count on it.
Re: Help with IMAP IDLE
On 27 Jul 2019, at 04:15, Jorge Bastos wrote: > When i migrated the account from the old imap server to the new (dovecot), i > didn't removed and created the account in msoutlook, as i didn't saw any > reason to do it. > Creating the account again, IDLE works ok! Glad you got that figured out. Seems like a weird one. -- CURSIVE WRITING DOES NOT MEAN WHAT I THINK IT DOES Bart chalkboard Ep. 2F11
Re: Dovecot, FreeBSD, and Solr?
On 27 Jul 2019, at 00:42, Patrick Mahan wrote: > On Fri, Jul 26, 2019 at 2:44 PM @lbutlr via dovecot > wrote: > On 26 Jul 2019, at 09:35, dove...@filter.demeijer.com wrote: > > I basically followed https://www.c0ffee.net/blog/mail-server-guide/ And > > dovecot with solr is running fine on freebsd for me. > > Thanks for that link, looks very straight-forward. > > > I too followed that guide for setting up dovecot+postfix+solr. The one major > caveat is that the binary dovecot package does not have solr support and I > had to build it from the port source tree and enable it. I had some sort of issue and didn’t have time to look into it, so disabled solr (everything was being deferred). The configuration is right, but I think he maxprocess setting on my freebsd is very old, out of date, and low (solr threw a warning that I needed to increase it) -- Law of Probability Dispersal: Whatever hits the fan will not be evenly distributed.
Re: submission configuration issues
On 23/07/2019 17:13, Jean-Daniel Dupas via dovecot wrote: Hello, I'm having trouble configuring the submission proxy. I have configured the submission service as follow: submission_host = smtp.example.com submission_relay_host = localhost submission_relay_port = 8587 submission_relay_rawlog_dir = /var/log/dovecot/ submission_relay_trusted = yes My main issue is that until I login, dovecot-submission won't connect to the backend and query the capabilities and so won't report the right capabilities. That mean that the first EHLO message don't get the right capabilities list. " EHLO example.com 250-smtp.example.com 250-8BITMIME 250-AUTH PLAIN LOGIN 250-BURL imap 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-SIZE 250 PIPELINING " This list don't contains VRFY, DNS, and SIZE is not specified (all of these is present in backend EHLO response). After login, if I send an new EHLO command, everything is properly reported. The raw log shows that unlike what the documentation says, dovecot don't try to connect to the backend until the user is properly logged. In my raw log I show that after I logged in dovecot-submission, the later open a connection to the backend and send a X-CLIENT command. Now, if I try to force the capabilities by using: submission_backend_capabilities = VRFY 8BITMIME DSN dovecot properly reports all SMTP capabilities in the first EHLO response, but it completely stops emitting X-CLIENT command to the backend and try to simply forward the command without authentication, which result in postfix rejecting the command with an unauthorized user error. What is wrong with my configuration ? Thanks. Can you send us your complete configuration (output from `dovecot -n`)? Regards, Stephan.
Re: Autoexpunge not working for Junk?
On 25 Jul 2019, at 7.18, Amir Caspi via dovecot wrote: > > Hi all, > > I set up dovecot a couple of months ago and am having trouble getting > autoexpunge=30d to work on my Trash and Junk mailboxes. Not sure why not > because I'm not getting error messages in my log. > Running "doveadm search -u mailbox Junk savedbefore 30d" shows > me many messages (I've got messages back to mid-May, and a couple of other > users have them back to early April, although if this setting were working, > there should be nothing earlier than June 24). Running a manual doveadm > expunge works fine... it's just autoexpunge that seems to not be running at > all. Autoexpunging tries to be efficient, so it looks only at the first email's saved-timestamp. It's also cached in dovecot.list.index. So you should check: 1. What's the first mail's saved-timestamp? doveadm fetch -u user date.saved mailbox Junk 1 2. That timestamp should also be the same in dovecot.list.index: doveadm mailbox status -u user firstsaved Junk
Re: corrupt mdbox index / zero mails showing in imap
On 27 Jul 2019, at 14.13, Timo Sirainen wrote: > > On 25 Jul 2019, at 20.55, Mike via dovecot wrote: >> >> Hi, >> >> >> I have recently migrated (under emergency conditions) a dovecot imap/pop >> based server to a new instance. The mailboxes used mdbox format and due >> to various screwups I had corrupt indexes. I thought I'd cleaned this up >> but then I found that this new instance hadn't been set up correctly for >> nfs. Long story short, I still get users with new cases of corrupt >> indexes. The symptom is imap either showing NO mail in their inbox, or, >> not showing any recently delivered mail in the box, until I rm -f >> dovecot.map.index / doveadm force-resync -u user. >> >> It would be a huge help if there could be some method to detect if this >> is the case for any given user and to proactively do the force-resync >> process for them instead of waiting for that support call (or service >> cancellation...). I have looked around and have not found any tool >> capable of 'linting' an mdbox format inbox, and it seems like something >> like this should have been or would be an extremely useful debugging >> tool both during development as well as to troubleshoot stuff in the >> field. I would love to know if anyone either has such a tool, or any >> general suggestion how I could go about finding these cases and >> addressing them. I believe I have the nfs issue resolved and will not be >> creating new cases, so I just want to fix the ~3000 boxes I have now and >> move forward. > > > I think you could do something with using "doveadm dump" command. I'm not > sure in what ways your mdboxes are corrupted, so there might be an easier way > to do it, but for a generic checker I think this would work: > > * doveadm dump dovecot.map.index and remember all the "uid" numbers > * doveadm dump dovecot.index for each folder and remember all the "map_uid" > numbers. > * See if any map_uid is missing in dovecot.map.index's uid numbers. yes -> > force-resync > > You can also use doveadm dump for the storage/m.* files to see what they > contain, but this likely won't be useful for this case. Or actually reading further: It looks like all your indexes are gone, even the folders' dovecot.index* files? Wouldn't a simple solution then be just to check if "doveadm mailbox status" if the user looks empty (or mostly empty) you'd run the force-resync? Or another thought: If INBOX's dovecot.index was completely lost and was recreated, you can see the index's creation timestamp in the "indexid" field in "doveadm dump dovecot.index" - if it's new enough do the force-resync. BTW. If all the indexes are gone, force-resync adds all storage/m.* mails back to their original folder. So if user had moved mails to another folder they come back to e.g. INBOX. It also loses message flags, and brings back mails that were already expunged but not yet doveadm purged.
Re: corrupt mdbox index / zero mails showing in imap
On 25 Jul 2019, at 20.55, Mike via dovecot wrote: > > Hi, > > > I have recently migrated (under emergency conditions) a dovecot imap/pop > based server to a new instance. The mailboxes used mdbox format and due > to various screwups I had corrupt indexes. I thought I'd cleaned this up > but then I found that this new instance hadn't been set up correctly for > nfs. Long story short, I still get users with new cases of corrupt > indexes. The symptom is imap either showing NO mail in their inbox, or, > not showing any recently delivered mail in the box, until I rm -f > dovecot.map.index / doveadm force-resync -u user. > > It would be a huge help if there could be some method to detect if this > is the case for any given user and to proactively do the force-resync > process for them instead of waiting for that support call (or service > cancellation...). I have looked around and have not found any tool > capable of 'linting' an mdbox format inbox, and it seems like something > like this should have been or would be an extremely useful debugging > tool both during development as well as to troubleshoot stuff in the > field. I would love to know if anyone either has such a tool, or any > general suggestion how I could go about finding these cases and > addressing them. I believe I have the nfs issue resolved and will not be > creating new cases, so I just want to fix the ~3000 boxes I have now and > move forward. I think you could do something with using "doveadm dump" command. I'm not sure in what ways your mdboxes are corrupted, so there might be an easier way to do it, but for a generic checker I think this would work: * doveadm dump dovecot.map.index and remember all the "uid" numbers * doveadm dump dovecot.index for each folder and remember all the "map_uid" numbers. * See if any map_uid is missing in dovecot.map.index's uid numbers. yes -> force-resync You can also use doveadm dump for the storage/m.* files to see what they contain, but this likely won't be useful for this case.
RE: Help with IMAP IDLE
Guys, I just discovered the reason! When i migrated the account from the old imap server to the new (dovecot), i didn't removed and created the account in msoutlook, as i didn't saw any reason to do it. Creating the account again, IDLE works ok! Stupid outlook! Sorry for the noise, and thank you for the help, -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Tuesday, July 23, 2019 23:32 To: 'Dovecot Mailing List' Subject: RE: Help with IMAP IDLE Well, I've been doing some research, and it seems that msoutlook 2016 and 2019 doesn't quite have imap idle support. The odd part, is that when i had DBMail, it was IDLE'ing (i swear), Would dbmail send something different that make it work? It was an old version of dbmail, 2.3.7 i believe, from about 2012 or so. And no, it wasn't the outlook options "send/receive", i had and have that disabled, Don't have explanation, thunderbird IDLE's perfectly -Original Message- From: dovecot On Behalf Of Jorge Bastos via dovecot Sent: Tuesday, July 23, 2019 22:47 To: 'Dovecot Mailing List' Subject: RE: Help with IMAP IDLE Yes, Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] > Yes, it works with other IMAP servers, why should not work with dovecot? > It was working with DBMail, and it's working with an account from my > Telco that used cirus-imap. Have you verified (with rawlogs or tcpdump) that outlook even attempts IDLE? Is your dovecot advertising IDLE support in CAPABILITY? Sami
Re: Dovecot, FreeBSD, and Solr?
On Fri, Jul 26, 2019 at 2:44 PM @lbutlr via dovecot wrote: > On 26 Jul 2019, at 09:35, dove...@filter.demeijer.com wrote: > > I basically followed https://www.c0ffee.net/blog/mail-server-guide/ And > > dovecot with solr is running fine on freebsd for me. > > Thanks for that link, looks very straight-forward. > > I too followed that guide for setting up dovecot+postfix+solr. The one major caveat is that the binary dovecot package does not have solr support and I had to build it from the port source tree and enable it. > > -- > Nothing says poor craftsmanship more than wrinkled duct tape. > >
