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.  Anyway, I'll leave the thread but would like to hear about the final solution.   Original Message   From: Michael Fox Sent:

Re: controlling STARTTLS by IP address

On 16-07-14 16:07:53, M. Balridge wrote: > Quoting Michael Fox : > > > > 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

RE: controlling STARTTLS by IP address

Quoting Michael Fox : > > 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. It looks like there's an internal

RE: controlling STARTTLS by IP address

> You could try > > remote x.x.x.x/y { >ssl = no > } > > Aki That works! Thanks SO much! Michael

Re: controlling STARTTLS by IP address

On 15.07.2016 00:52, Michael Fox wrote: You could try remote x.x.x.x/y { ssl = no } Aki Wow. OK. But I can find no documentation on how to use that. Would it be used inside service pop3-login, or at the top level? And, does it apply the first match found? For example: # Disable

RE: controlling STARTTLS by IP address

> > You could try > > remote x.x.x.x/y { >ssl = no > } > > Aki Wow. OK. But I can find no documentation on how to use that. Would it be used inside service pop3-login, or at the top level? And, does it apply the first match found? For example: # Disable SSL for radio clients

RE: controlling STARTTLS by IP address

> Are you 100% sure your interpretation of the FCC rules is correct? Yes > Do you really want passwords going out over RF unencrypted? No. I don't plan to use plaintext auth methods. > As far as I know, only ham bands are not allowed to use encryption. Even > baby monitors these days are DECT.

RE: controlling STARTTLS by IP address

> 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. Michael

Re: controlling STARTTLS by IP address

On 15.07.2016 00:13, Edgar Pettijohn wrote: Sent from my iPhone On Jul 14, 2016, at 3:56 PM, Michael Fox wrote: On my POP3 server, I need to be able to control the use of STARTTLS by client IP address. Specifically: * Clients on certain internal subnets (e.g.,

Re: controlling STARTTLS by IP address

Are you 100% sure your interpretation of the FCC rules is correct? Do you really want passwords going out over RF unencrypted?  As far as I know, only ham bands are not allowed to use encryption. Even baby monitors these days are DECT. (Mind you, not good encryption.)   Original Message  

Re: controlling STARTTLS by IP address

Sent from my iPhone > On Jul 14, 2016, at 3:56 PM, Michael Fox wrote: > > On my POP3 server, I need to be able to control the use of STARTTLS by > client IP address. Specifically: > > * Clients on certain internal subnets (e.g., 192.168.1.0/24) must not have > the option to

controlling STARTTLS by IP address

On my POP3 server, I need to be able to control the use of STARTTLS by client IP address. Specifically: * Clients on certain internal subnets (e.g., 192.168.1.0/24) must not have the option to use TLS. If the client tries to use STARTTLS, the option should be rejected. This is to satisfy US

Re: "Error: nfs_flush_file_handle_cache_dir: rmdir(/inboxes)" log spikes

On 14.07.2016 21:26, Joseph Tam wrote: I received a bunch of these log messages at a rate of a few thousand per hour for one of my users -- she may have max'd out her quota. The directory is a NFS directory containing mbox formatted INBOX's. Other than alleviating the space crunch, is

"Error: nfs_flush_file_handle_cache_dir: rmdir(/inboxes)" log spikes

I received a bunch of these log messages at a rate of a few thousand per hour for one of my users -- she may have max'd out her quota. The directory is a NFS directory containing mbox formatted INBOX's. Other than alleviating the space crunch, is there any particular action I need to take?

Re: Panic: file mail-transaction-log-file.c: line 104 (mail_transaction_log_file_free): assertion failed: (!file->locked)

On 14.07.2016 10:56, Arkadiusz Miśkiewicz wrote: 2.2.25 (also happens on 2.2.24). Happens every time I try to make deliver and only for this user: Hi! Any chance for doveconf -n + gdb bt full output from coredump? gdb /path/to/lmtp /path/to/core bt full Aki Tuomi Dovecot oy

quota config - when is the warning messag send?

Hi, we run dovecot 2.2.24 and from what I see, quota management with warning message is configured currently with "noenforcing". Our individual quota limit is stored in the users ldap DN which is fetched as I see from the logs and by "doveadm quota get -u" I tried to trigger the warning mail by

Panic: file mail-transaction-log-file.c: line 104 (mail_transaction_log_file_free): assertion failed: (!file->locked)

2.2.25 (also happens on 2.2.24). Happens every time I try to make deliver and only for this user: Jul 14 09:52:02 mbox dovecot: lmtp(25601): Connect from local Jul 14 09:52:02 mbox dovecot: lmtp(powiadomienia): session=, Error: Index /var/mail/powiadomienia/dovecot.index: Lost log for seq=1009