similar to: 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. (Mind you, not good encryption.) Correct. It is ham radio. Michael

> 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) authentication without TLS over ham frequencies. Hashed challenge/response

On 15.07.2016 00:13, Edgar Pettijohn wrote: > > Sent from my iPhone > >> On Jul 14, 2016, at 3:56 PM, Michael Fox <news at mefox.org> 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

> 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

For some unfathomable reason, Siemens USA doesn't offer the Gigaset IP range in the U.S. I'm particularly interested in the Gigaset S685 IP. Since it's DECT 6.0, and there's an English (UK) version, I'm thinking it should work just fine, after dealing with the walwart issue (and maybe caller ID signalling). Anyone imported one from the UK and using it in the US? for how

Now that I actually try and google for it, I can't find any dual mode GSM/DECT handsets, only pages telling me that they exist without any actual information!!! Does anyone know of any such handsets? (and even better, ones that are available in Australia) I've searched a few of the major gsm manufacturers (nokia, Panasonic, sonyericsson) but their web sites are absolutely pathetic to the

Hi List, I have a dovecot which proxies to different backends depending on an entry in a mysql-database. The mysql-query sets ?ssl? to ?any-cert? and this works fine. But this causes me a problem: sieve-backends only support STARTTLS and if I set ?ssl? to ?any-cert? (or yes), it will attempt a TLS-connection to the sieve-backends, which fails. My attempt was to alter the query to include

Hi, I would like to disable offering starttls to clients for certain dovecot services. Background is that I want to do let a load balancer do the TLS stuff right on connect time and let dovecot only do plain imap without offering starttls (because the clients do imaps actually). Getting rid of the starttls feature offering works only if I set ssl = no globally only. Setting it in the service

I believe I have the configuration set to use START TLS on IMAP4 (143) and POP3 (110) ports. ?However, it does not seem to be working. ?Yet "STARTTLS" is listed as a capability (which tells me I probably do have it configured right). In the session below, 172.30.0.24 is the mail server I'm putting up. 64.26.60.229 is an outside mail service. A similar thing happens on POP3. The

Hi All, I am runnig sendmail 8.12.8. I am getting the below error. [root at mail MailScanner]# tail -f /var/log/maillog Jan 11 11:20:40 mail sendmail[10646]: STARTTLS: read error=generic SSL error (0) Jan 11 11:20:41 mail last message repeated 22494 times Jan 11 11:20:41 mail sendmail[10646]: STARTTLS: read error=generic SSL error (0) Jan 11 11:20:41 mail last message repeated 8894 times Jan 11

Hi I got dovecot 2.2.26 on a Centos7 with latest updates. Dovecot is configured to act as director and delivers to my two backend servers. I enabled lmtp proxy on director to listen on port 24. Now I see in msg headers that the connection to the lmtp proxy uses STARTTLS but the connection from proxy to backend seems to be unencrypted. Is it possible to enforce the use of STARTTLS in the

Hi all, Is there a way to enforce STARTTLS for all connections, regardless their authentication mechanism? disable_plaintext_auth only takes care of the auth conversation, but I would like to have all communication encrypted. As far as I can see, this would only be possible when using imaps and disabling imap. However, I would like to have the other way around; disabling imaps and using imap for

I have a user who has Mac OS 10.4.8 with Entourage X. The email server is sendmail 8.13.8 and is setup to use STARTTLS on a CentOS 4.4 system. It appears from everything I have googled that only Entourage 2004 will properly function with STARTTLS. Has anybody any experience with Entourage X ... specifically is there something I am missing regarding the CentOS server setup or are all Entourage

Hi, I have a postfix+dovecot-2.2.13 system and have configured it to support IMAPS on 993 with SSL/TLS. I'm noticing with users using Thunderbird, the autodetect defaults to IMAPS on 143 with STARTTLS. Which is preferred? Which is more secure? Which is more common? Why would someone choose one over the other? Can I ask the same question about SMTP and submission? Why would one choose 587

I wanted to enable SSL on some alternate ports so that a limited number of people could try SSL access. But doing so enabled STARTTLS in IMAP, so that all IMAP users got surprised (at least those whose clients attempted to use it automatically). e.g.: # IP or host address where to listen in for SSL connections. Defaults # to above non-SSL equilevants if not specified. imaps_listen =

Hi, I'm having a bit of a problem trying to setup a dovecot proxy. I have a setup with two nodes. One is a working Dovecot/Postfix mail server (node a). The other is running a dovecot proxy and roundcube webmail. Currently I can telnet to port 143 (or openssl s_client to port 993) to localhost on node b. I can then login to a test account on node a. This all works. However, once I instruct

I'm testing my new dovecot server with Thundirbird I can have it working on port 143 with STARTTLS, or on port 993 with SSL/TLS my uderstanding is that on 993 I get encrypted 'password and mail transfer' (yes ?) so what happens if I use 143 with STARTTLS, is that equivalent to port 993 if STARTTLS is used ? thanks for any insights.. -- Voytek

NOTE: LMTP/doveadm proxying doesn't support SSL/TLS currently - any ssl/starttls extra field is ignored https://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy Am 23. November 2017 09:31:41 MEZ schrieb Tobi <tobisworld at gmail.com>: >Hi > >I got dovecot 2.2.26 on a Centos7 with latest updates. Dovecot is >configured to act as director and delivers to my two backend

Greetings - I have been looking at Dovecot with a view to migrating us to it from the Washington IMAP server on our Sun systems. To start our testing we first of all installed the pre-built version of Dovecot from the Blastwave (www.blastwave.org) community supported packaged software site. This was Dovecot 0.99.10.4 and we successfully got it working in our test environment: at first just

Hi there, We are using DoveCot 1.0.7. User will use POP3 or POP. We want to force user to securely send their credential and keep a secure connection between us and them. We can do TLS/SSL on port 995, or STARTTLS on port 110. The problem is that we have no way to enforce STARTTLS on 110, user can connect to DoveCot on port 110, sending user credential without STARTTLS (thus insecure).