Moving Maildir folders

Our office had a user leave. Another user is taking over her duties and needs reference to the departing user's email. I've copied that entire departed user's Maildir structure to the current user: mv olduser/Maildir/.* curuser/Maildir/.olduser I did change permission and ownership on

doveconf -n display error for "remote"

Upon further testing, it seems that the issue below may only be a display bug in doveconf. In other words, the remote filter appears to work as configured, even though it is displayed with duplicate prefix length by doveconf. Is this sufficient information to report a bug or is there some other

RE: controlling STARTTLS by IP address

KSB: > Just curious, it is transferred in some RSxxx serial protocol? The expectation is that the unencrypted traffic will be used for clients on an Ethernet network behind a radio operating on amateur radio frequencies according to FCC Part 97 rules. The radio could be: -- 56+kbps UHF, such

Re: Doveadm error

> On July 12, 2016 at 4:30 PM László Károlyi wrote: > > > Hey everyone, > > I've got a weird error since I upgraded to the latest dovecot on my FreeBSD > box: > > root@postfixjail /# doveadm quota recalc -u x...@xxx.com > doveadm(x...@xxx.com): Error: dict-client: Commit

Doveadm error

Hey everyone, I've got a weird error since I upgraded to the latest dovecot on my FreeBSD box: root@postfixjail /# doveadm quota recalc -u x...@xxx.com doveadm(x...@xxx.com): Error: dict-client: Commit failed: Deinit fish: 'doveadm quota recalc -u xxx@…' terminated by signal SIGSEGV (Address

Re: controlling STARTTLS by IP address

On 2016.07.15. 11:03, Michael Fox wrote: I'm not a FCC lawyer, just a ham. Seems to me all you could do is "sign" messages and not send them if the sign isn't correct. The package itself is in plain text. I'm not sure what the confusion or concern is. The intention is to use non-plaintext

RE: RE: controlling STARTTLS by IP address

> -Original Message- > From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of Jochen > Bern > Sent: Friday, July 15, 2016 12:46 AM > To: dovecot@dovecot.org > Subject: Re: RE: controlling STARTTLS by IP address > > On 07/14/2016 11:52 PM, Michael Fox wrote: > >> Seems like your

RE: controlling STARTTLS by IP address

> I'm not a FCC lawyer, just a ham. Seems to me all you could do is "sign" > messages and not send them if the sign isn't correct.  The package itself > is in plain text. I'm not sure what the confusion or concern is. The intention is to use non-plaintext (but technically not encrypted)

Re: RE: controlling STARTTLS by IP address

On 07/14/2016 11:52 PM, Michael Fox wrote: >> Seems like your firewall could redirect to a different port that doesn't >> offer starttls. > Yes, of course. But that would require multiple ports, making the client > configuration cumbersome and error-prone. No, the multiple ports would be on the

authentication failed: Connection lost to authentication server

Dear all, I got error "authentication failed: Connection lost to authentication server", i turned on debug mode in Postfix/Dovecot, but this is the error i can get. All other errors point to sasl auth failure, what does "connection lost to authentication server" means? How can i exactly know

Re: controlling STARTTLS by IP address

On 2016.07.15. 2:07, M. Balridge wrote: I just thought to remind people that with some firewalls, there's always a way to perform "silent" redirections using the DNAT target in the PREROUTING table, i.e.,: -t nat -A PREROUTING -i ${EXTIF} -s ${NOTLSSOURCES} -p tcp --dport 110 \ --syn -j DNAT

RE: controlling STARTTLS by IP address

> > I just thought to remind people that with some firewalls, there's always > a way > > to perform "silent" redirections using the DNAT target in the PREROUTING > > table, i.e.,: > > > > -t nat -A PREROUTING -i ${EXTIF} -s ${NOTLSSOURCES} -p tcp --dport 110 \ > > --syn -j DNAT --to-destination