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 as
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 (bu
> -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 wro
> 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) authentic
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 *
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
> > 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 ${
From: Michael Fox
Sent: Thursday, July 14, 2016 2:54 PM
To: 'Dovecot Mailing List'
Subject: 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
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 and error-prone.
>
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 Dovecot solution, so
> You could try
>
> remote x.x.x.x/y {
>ssl = no
> }
>
> Aki
That works! Thanks SO much!
Michael
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
>
> 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
remot
> 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. (
> 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
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., 192.168.1.0/24) must not ha
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
Fro
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 use TLS. If the
18 matches
Mail list logo
