How to restrict encrypted email

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

How to restrict encrypted email

Michael Fox
I'd like to be able to reject mail that contains encrypted content.  This is
to satisfy US FCC rules against encrypted content on amateur radio
frequencies.  Some of our clients may connect via amateur radio.

I'd like to be able to restrict it only for certain clients.  But, as I
understand it, header checks can only be applied globally, to all mail.

Sorry if this is a dumb question.  But, unfortunately, I don't have any
experience with encrypted mail.  From what I've read, I'm thinking I need:

main.cf:

  mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre


mime_header_checks.pcre:

  # Block encrypted mail
  /^Content-Type\:.*multipart\/encrypted/ REJECT Encrypted
content not allowed



Is that sufficient?
Any better ideas or other issues to consider?

Thanks,
Michael


Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Marco-3
Hello Michael.

It is a near impossible task, as i.e. encrypted data can easily be
transferred as uuencode text in a plain text message, and you will not
notice this in the headers.
And also trying to actively detected whether or not the body or the
attachments of a message are encrypted is quite tricky, and also
potentially prone to a number of positive false detections.
If this is not enough steganography and other methodologies can be used
to hide encrypted data, making the task really complex even for high-end
organizations....

More, you could maybe have some form of binding agreement with the
ham-radio operators, prohibiting the usage of encryption. However you
will be not able to have a such legal protection with all other Internet
users sending mails to the ham-radio users.

This means you have to decide whether or not you want to take the risk,
and if yes, maybe, minimize it with some filtering for the obvious cases
as you propose.

Have a nice day

Marco

Il 16. 07. 16 07:25, Michael Fox ha scritto:

> I'd like to be able to reject mail that contains encrypted content.  This is
> to satisfy US FCC rules against encrypted content on amateur radio
> frequencies.  Some of our clients may connect via amateur radio.
>
> I'd like to be able to restrict it only for certain clients.  But, as I
> understand it, header checks can only be applied globally, to all mail.
>
> Sorry if this is a dumb question.  But, unfortunately, I don't have any
> experience with encrypted mail.  From what I've read, I'm thinking I need:
>
> main.cf:
>
>   mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre
>
>
> mime_header_checks.pcre:
>
>   # Block encrypted mail
>   /^Content-Type\:.*multipart\/encrypted/ REJECT Encrypted
> content not allowed
>
>
>
> Is that sufficient?
> Any better ideas or other issues to consider?
>
> Thanks,
> Michael
>
>

Reply | Threaded
Open this post in threaded view
|

RE: How to restrict encrypted email

Michael Fox
> minimize it with some filtering for the obvious cases
> as you propose.

Thanks Marco.  I hadn't thought of some of those cases.  
But I would still like to block the obvious cases, as you say.

So, are there other obvious ways to recognize encrypted contents, other than
"Content-Type: multipart/encrypted"?

Thanks,
Michael



Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Albrecht Dreß
Am 16.07.16 15:59 schrieb(en) Michael Fox:
> So, are there other obvious ways to recognize encrypted contents, other than
> "Content-Type: multipart/encrypted"?

Basically, you need to check for
- OpenPGP/Inline (inspect every body, see rfc 2440, sect. 6.2)
- OpenPGP/Mime (multipart/encrypted, see rfc 3156, sect. 4)
- S/MIME (application/pkcs7-mime with a proper protocol type, see rfc 2633, sect. 3.8)

BTW, IMHO this is the *completely* wrong approach - people should be *encouraged* to use encryption, at least since we know for sure that their privacy is threatened everywhere...

Hth,
Albrecht.

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Phil Stracchino
On 07/16/16 10:32, Albrecht Dreß wrote:

> Am 16.07.16 15:59 schrieb(en) Michael Fox:
>> So, are there other obvious ways to recognize encrypted contents, other than
>> "Content-Type: multipart/encrypted"?
>
> Basically, you need to check for
> - OpenPGP/Inline (inspect every body, see rfc 2440, sect. 6.2)
> - OpenPGP/Mime (multipart/encrypted, see rfc 3156, sect. 4)
> - S/MIME (application/pkcs7-mime with a proper protocol type, see rfc 2633, sect. 3.8)
>
> BTW, IMHO this is the *completely* wrong approach - people should be *encouraged* to use encryption, at least since we know for sure that their privacy is threatened everywhere...
Anyone who knows Theresa May, former UK Home Secretary, just selected as
the new head of the Conservative party, will be unsurprised to know that
almost her first public position pronunciation was that she sees no
problem with passing laws in the UK to prohibit end-to-end encryption
and require ISPs et al to provide backdoors into all encrypted traffic.
Because, you know, that idea has no flaws *whatsoever* and has *never*
ended badly anywhere else...


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: 603.293.8485


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Erwan David
Le 16/07/2016 à 16:39, Phil Stracchino a écrit :

> On 07/16/16 10:32, Albrecht Dreß wrote:
>> Am 16.07.16 15:59 schrieb(en) Michael Fox:
>>> So, are there other obvious ways to recognize encrypted contents, other than
>>> "Content-Type: multipart/encrypted"?
>> Basically, you need to check for
>> - OpenPGP/Inline (inspect every body, see rfc 2440, sect. 6.2)
>> - OpenPGP/Mime (multipart/encrypted, see rfc 3156, sect. 4)
>> - S/MIME (application/pkcs7-mime with a proper protocol type, see rfc 2633, sect. 3.8)
>>
>> BTW, IMHO this is the *completely* wrong approach - people should be *encouraged* to use encryption, at least since we know for sure that their privacy is threatened everywhere...
> Anyone who knows Theresa May, former UK Home Secretary, just selected as
> the new head of the Conservative party, will be unsurprised to know that
> almost her first public position pronunciation was that she sees no
> problem with passing laws in the UK to prohibit end-to-end encryption
> and require ISPs et al to provide backdoors into all encrypted traffic.
> Because, you know, that idea has no flaws *whatsoever* and has *never*
> ended badly anywhere else...
>
>
And the fact that UK policemen where caught using snooping provision for
personal usage and financial gain won't stop her.



signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Jan Ceuleers
In reply to this post by Michael Fox
On 16/07/16 15:59, Michael Fox wrote:
> So, are there other obvious ways to recognize encrypted contents, other than
> "Content-Type: multipart/encrypted"?

Theoretical (and therefore possibly entirely impractical) answer:

Encrypted data contains a high amount of entropy, meaning that it does
not compress well. So that might be a way to detect encryption.

Trouble is, this method would also flag already-compressed data, even if
the compression has not been password-protected (and so arguably is not
encrypted).

So you could try a 2-step process: check whether the data is
compressible. If it is, assume that it is not encrypted. If it is not,
then check whether you can use the well-known MIME types or file
extensions to determine whether it contains compressed attachments. If
you can automatically decompress the attachment (i.e. without a
password), run the second check again, just to ensure that the
decompressed file does not again contain encrypted data.

This is expensive and recursive, so possibly open to a DoS attack
(unless you can put an upper bound on resource usage of the milter that
does this). Unless you also disallow compressed content even if not
password-protected, in which case you can omit the second step and
therefore the recursion.

Furthermore, you would not find steganographically hidden encrypted
content this way.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

/dev/rob0
In reply to this post by Michael Fox
On Fri, Jul 15, 2016 at 10:25:43PM -0700, Michael Fox wrote:
> I'd like to be able to reject mail that contains encrypted content.  
> This is to satisfy US FCC rules against encrypted content on
> amateur radio frequencies.  Some of our clients may connect via
> amateur radio.

I think you're taking it too far.  Consider that the regulation was
written by someone, and then ratified by a group, not one of whom had
ever heard of GPG.  For that matter, the regulation probably did not
anticipate packet radio use for IP traffic.  Surely they were only
thinking about scrambled radio voice traffic.

You have already discarded STARTTLS from your EHLO reply for packet
radio clients, and I think even that is going a bit too far.

If your interpretation of these FCC rules is accurate, you really
can't offer any kind of connection to the Internet in any way, even
indirect.  You can't possibly anticipate all kinds of cryptography
and steganography.

Israel's then-future-king David, and his friend, then Prince
Jonathan, cooked up and employed an encryption scheme in the Old
Testament.  If your interpretation stands, you cannot allow anyone to
say in email, "... is not the arrow beyond thee?" (KJV, 1 Samuel
20:37.)  That could contain a hidden message.

Don't let them push you down this slippery slope.  If you are really
worried about it, call the FCC or a private attorney and get a solid
interpretation.

> I'd like to be able to restrict it only for certain clients.  But,
> as I understand it, header checks can only be applied globally, to
> all mail.

[OOTC: obligatory on-topic content]

Yes, but you can use an alternate cleanup service on an alternate
smtpd instance, see postconf.5.html#cleanup_service_name and also
cleanup.8.html .

> Sorry if this is a dumb question.  But, unfortunately, I don't
> have any experience with encrypted mail.  From what I've read,
> I'm thinking I need:
>
> main.cf:
>
>   mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre
>
>
> mime_header_checks.pcre:
>
>   # Block encrypted mail
>   /^Content-Type\:.*multipart\/encrypted/ REJECT Encrypted
> content not allowed
>
>
>
> Is that sufficient?

No.  What about inline PGP/GPG messages?  What about encrypted
messages hidden inside image or audio files?

[/OOTC]

> Any better ideas or other issues to consider?

Don't do it.  See above.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Erwan David
In reply to this post by Jan Ceuleers
Le 16/07/2016 à 16:49, Jan Ceuleers a écrit :

> On 16/07/16 15:59, Michael Fox wrote:
>> So, are there other obvious ways to recognize encrypted contents, other than
>> "Content-Type: multipart/encrypted"?
> Theoretical (and therefore possibly entirely impractical) answer:
>
> Encrypted data contains a high amount of entropy, meaning that it does
> not compress well. So that might be a way to detect encryption.
>
> Trouble is, this method would also flag already-compressed data, even if
> the compression has not been password-protected (and so arguably is not
> encrypted).
>
> So you could try a 2-step process: check whether the data is
> compressible. If it is, assume that it is not encrypted. If it is not,
> then check whether you can use the well-known MIME types or file
> extensions to determine whether it contains compressed attachments. If
> you can automatically decompress the attachment (i.e. without a
> password), run the second check again, just to ensure that the
> decompressed file does not again contain encrypted data.
>
> This is expensive and recursive, so possibly open to a DoS attack
> (unless you can put an upper bound on resource usage of the milter that
> does this). Unless you also disallow compressed content even if not
> password-protected, in which case you can omit the second step and
> therefore the recursion.
>
> Furthermore, you would not find steganographically hidden encrypted
> content this way.
>
> Jan
>
I think that pursuing this way you will arrive to allowing only
text/plain messages.

And use some natural language testing on it because any base64 encoded
content can be announced as text/plain

Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Yuval Levy
In reply to this post by /dev/rob0
(Non-US) lawyer here, chiming in after the itch became to strong.
Initially I wanted to stay out of this debate, the solution of which is
obviously non-technical and probably OT.

DISCLAIMER: THE FOLLOWING IS NOT LEGAL ADVICE.

On 16-07-16 11:04 AM, /dev/rob0 wrote:
> You have already discarded STARTTLS from your EHLO reply for packet
> radio clients, and I think even that is going a bit too far.

In my view, that's the maximum extent to which an SMTP server operator
can be held liable.  I'd disable STARTTLS and forget about the rest.

Principle of the rule of law: if a law can't be possibly followed, no
court in a rule of law country will enforce it.  There is enough
indication in this thread that it is technically impossible to prevent
users from concealing the content of their communication while using
your SMTP server.


> If your interpretation of these FCC rules is accurate, you really
> can't offer any kind of connection to the Internet in any way, even
> indirect.  You can't possibly anticipate all kinds of cryptography
> and steganography.

It is indeed a matter of interpretation, and I would like to see the FCC
rules text.  Questions:
(1) how do they define "encrypted"?
(2) on who is the obligation imposed?

Imposing the onus on the SMTP server operator is like imposing the onus
on gas stations for fueling vehicles used in criminal endeavors.  It
does not fly because the gas station can't possibly know what the user
will use the vehicle for, other than (probably) driving.

By the definition of encryption, an SMTP server operator can't possibly
know that a message is encrypted unless the end-user is kind enough to
say so, e.g. in the MIME headers.


> Don't let them push you down this slippery slope.  If you are really
> worried about it, call the FCC or a private attorney and get a solid
> interpretation.

If I was the SMTP server operator and they came to me, I'd tell them to
take a walk.

If they came back and fined me I would not pay and tell them to take a
longer walk.

If they came back and sued me, I would defend in court and argue that
the rule is not enforceable against the SMTP server operator because
technically impossible to comply with.  I would tell them to take an
even longer walk until they may guess that the rule may be enforceable
against the end-user.

If they came to me and ask for the end-user information, I would tell
them to get a warrant.

If they showed me a valid warrant, I would dump on them my log files (or
a justification why I do not keep log files) and tell them good luck.

Yuv


Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Jan Ceuleers
On 16/07/16 17:42, Yuval Levy wrote:
> Imposing the onus on the SMTP server operator is like imposing the onus
> on gas stations for fueling vehicles used in criminal endeavors.  It
> does not fly because the gas station can't possibly know what the user
> will use the vehicle for, other than (probably) driving.

You have ignored the OP's statement that he is a radio amateur, and that
the FCC prohibits the use of encryption by radio amateurs. This is about
ensuring that the spectrum that radio amateurs are licensed to use (a
public resource) is not subverted for private purposes. Hams are
supposed to be a largely self-policing community; encryption prevents that.

As an individual radio amateur, the OP needs to ensure that he complies
with the FCC rules if he wants to keep his license. If he cannot
configure his SMTP server in a compliant manner he should not offer an
SMTP-based service that transports messages across the ham frequencies.
Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Erwan David
Le 16/07/2016 à 19:04, Jan Ceuleers a écrit :

> On 16/07/16 17:42, Yuval Levy wrote:
>> Imposing the onus on the SMTP server operator is like imposing the onus
>> on gas stations for fueling vehicles used in criminal endeavors.  It
>> does not fly because the gas station can't possibly know what the user
>> will use the vehicle for, other than (probably) driving.
> You have ignored the OP's statement that he is a radio amateur, and that
> the FCC prohibits the use of encryption by radio amateurs. This is about
> ensuring that the spectrum that radio amateurs are licensed to use (a
> public resource) is not subverted for private purposes. Hams are
> supposed to be a largely self-policing community; encryption prevents that.
>
> As an individual radio amateur, the OP needs to ensure that he complies
> with the FCC rules if he wants to keep his license. If he cannot
> configure his SMTP server in a compliant manner he should not offer an
> SMTP-based service that transports messages across the ham frequencies.
>
Wouldn't this mean that data transport on those frequencies is forbidden ?

Reply | Threaded
Open this post in threaded view
|

RE: How to restrict encrypted email

Michael Fox
In reply to this post by Albrecht Dreß
Michael Fox:
> > So, are there other obvious ways to recognize encrypted contents, other
> than
> > "Content-Type: multipart/encrypted"?

Albrecht:
> Basically, you need to check for
> - OpenPGP/Inline (inspect every body, see rfc 2440, sect. 6.2)
> - OpenPGP/Mime (multipart/encrypted, see rfc 3156, sect. 4)
> - S/MIME (application/pkcs7-mime with a proper protocol type, see rfc
> 2633, sect. 3.8)

Ah, OK.  That will give me a good start.  Thanks.


Rob0:
> you can use an alternate cleanup service on an alternate
> smtpd instance, see postconf.5.html#cleanup_service_name and also
> cleanup.8.html .

Interesting.  I hadn't thought of that.  I'll check into that.


And thanks to everyone for the rest of the comments, legal or otherwise.

I don't want to hijack this list with amateur radio stuff.  But to briefly
respond to those who took the time to respond to me:

-- Encryption should be encouraged:  Generally agreed.  But it's not allowed
on US amateur radio frequencies.

-- All comments about the FCC rules:  I have talked to the FCC and am
confident that I understand the requirements.  

-- You can never block it all:  Understood.  I'm looking to block the
obvious stuff to avoid inadvertent mistakes.  Those who resort to subterfuge
(which hasn't been a problem so far) can be dealt with on an individual
basis as a violation of the acceptable use policy.

Thanks again to all,
Michael


Reply | Threaded
Open this post in threaded view
|

Re: How to restrict encrypted email

Larry Stone
In reply to this post by Erwan David

> On Jul 16, 2016, at 11:11, Erwan David <[hidden email]> wrote:
>
>> Le 16/07/2016 à 19:04, Jan Ceuleers a écrit :
>>> On 16/07/16 17:42, Yuval Levy wrote:
>>> Imposing the onus on the SMTP server operator is like imposing the onus
>>> on gas stations for fueling vehicles used in criminal endeavors.  It
>>> does not fly because the gas station can't possibly know what the user
>>> will use the vehicle for, other than (probably) driving.
>> You have ignored the OP's statement that he is a radio amateur, and that
>> the FCC prohibits the use of encryption by radio amateurs. This is about
>> ensuring that the spectrum that radio amateurs are licensed to use (a
>> public resource) is not subverted for private purposes. Hams are
>> supposed to be a largely self-policing community; encryption prevents that.
>>
>> As an individual radio amateur, the OP needs to ensure that he complies
>> with the FCC rules if he wants to keep his license. If he cannot
>> configure his SMTP server in a compliant manner he should not offer an
>> SMTP-based service that transports messages across the ham frequencies.
> Wouldn't this mean that data transport on those frequencies is forbidden ?
>

I agree. Encryption does not imply TLS. A message could be encrypted while still being plain text. For a sufficiently low level definition of encryption, it could even be encrypted while appearing to be unencrypted. For instance, if two people agree that certain words means something different than their commonly accepted meanings, they could communicate in a form that appears to be plain language yet have a different meaning to them than to someone who intercepts it. But the latter example would also apply to voice communications in the amateur bands so since you can't be sure that even voice is unencrypted, I guess they aren't legal either.

-- Larry Stone
   [hidden email]
Reply | Threaded
Open this post in threaded view
|

SV: How to restrict encrypted email

Sebastian Nielsen
In reply to this post by Michael Fox
The problem you got, is that the encrypted content has already travelled the
amateur frequencies even if you block/reject the mail.
Thus the rules are already broken, thus you should deal with those users in
a "AUP" way even if the mail gets blocked. Better might be to block this in
firewall then.
I guess you intend to operate a outgoing mail relay now.

You could use iptables to look for:
"--BEGIN"
"--END"
"/signed"
"/encrypted"
"/pkcs7"
"/pgp"

Anywhere in the packet. In that case, you drop the connection, send  a RST
to source and target, and then you could ban the user account involved.

You can look here how to do with IP-tables, both for blocking encrypted
content, but also triggering some sort of ban.
http://blog.nintechnet.com/how-to-block-w00tw00t-at-isc-sans-dfind-and-other
-web-vulnerability-scanners/
You can also use Fail2Ban for this, and trigger ban based on user account.

(NOTE: Signed content is technically encrypted content too)

-----

If you instead operate a incoming mail relay (so internet users can send
messages to amateur radio operators), you said this would only apply to
certain users.
Then its better to block this on IMAP/POP3 level, as the users in question
might connect over public internet. Eg, encrypted mail is received and
stored, but it will never
Be delivered if the user is doing the fetch over radio frequencies (you
could instead send some auto message like "You have 1 new encrypted
message", but if the user happens to fetch over the public internet, then
they get any encrypted content.


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: How to restrict encrypted email

Michael Fox
> You could use iptables to look for:
> "--BEGIN"
> "--END"
> "/signed"
> "/encrypted"
> "/pkcs7"
> "/pgp"


Thanks to all.  I've got enough to get me started with my homework.  Lots to
learn.

Regards,
Michael



Reply | Threaded
Open this post in threaded view
|

(OT)Ham Radio + SMTP (was Re: How to restrict encrypted email)

j debert
In reply to this post by Yuval Levy
On Sat, 16 Jul 2016 11:42:44 -0400
Yuval Levy <[hidden email]> wrote:

> It is indeed a matter of interpretation, and I would like to see the
> FCC rules text.  Questions:
> (1) how do they define "encrypted"?

The rules and regulations are very clear on what is permitted. They do
not need to define anything else.

> (2) on who is the obligation imposed?

On all licensed amateur radio operators.

>
> Imposing the onus on the SMTP server operator is like imposing the
> onus on gas stations for fueling vehicles used in criminal
> endeavors.  It does not fly because the gas station can't possibly
> know what the user will use the vehicle for, other than (probably)
> driving.
>
> By the definition of encryption, an SMTP server operator can't
> possibly know that a message is encrypted unless the end-user is kind
> enough to say so, e.g. in the MIME headers.
>
>
> > Don't let them push you down this slippery slope.  If you are
> > really worried about it, call the FCC or a private attorney and get
> > a solid interpretation.
>
> If I was the SMTP server operator and they came to me, I'd tell them
> to take a walk.

The encryption ban dates almost from the earliest days of ham radio. It
has included unencrypted digital communications formats as well. It has
been extremely restrictive until recently. The use of ASCII was
prohibited until recently, for example. Violation of the regulations
can result in severe fines and forfeiture of license and equipment.

These are regulations, not laws. There is no due process as there
may be in criminal cases. It's a completely different legal universe.
Enforcement of regulations is administrative and not dealt with in the
courts, until criminal enforcement is necessary.

Please review part 97 of the FCC regulations, which pertains to amateur
radio operation. For the FCC's authority, that would be in Title 47 of
the United States Code.

Reply | Threaded
Open this post in threaded view
|

Re: SV: How to restrict encrypted email

Albrecht Dreß
In reply to this post by Sebastian Nielsen
Am 16.07.16 21:30 schrieb(en) Sebastian Nielsen:
> You could use iptables to look for:
> "--BEGIN"
> "--END"
> "/signed"
> "/encrypted"
> "/pkcs7"
> "/pgp"
>
> Anywhere in the packet. In that case, you drop the connection, send  a RST

IMO this is too restrictive as it would produce false positives, e.g. for your message which is obviously not encrypted.

For rfc 2633/3156, it would be sufficient to inspect the mime headers of all parts.  Note that just looking at the top-level content type is /not/ adequate, as the following would fully comply with the standards:

multipart/mixed
  +- text/plain
  +- message/rfc822
      +- multipart/encrypted
          +- application/pgp-encrypted
          +- application/octet-stream

For rfc 2440, every mime part must be checked for "-----BEGIN PGP MESSAGE-----[cr][lf]" *and* "-----END PGP MESSAGE-----[cr][lf]" following it (not necessarily at the very beginning and end, though).

I guess you need a milter for that...

> (NOTE: Signed content is technically encrypted content too)

The signature is a cryptographic hash, encrypted with a private key, which in turn can be decrypted with publicly available material (the public key).  Thus, IMO this should rather be considered as a "safe encoding", as it is possible to inspect the contents with minimum effort.

But attachments are difficult to deal with - ZIP, OpenDoc, MS Office, PDF, ... all support encrypted (with a password for opening) contents...

Cheers
Albrecht.

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: (OT)Ham Radio + SMTP (was Re: How to restrict encrypted email)

Curtis Villamizar-2
In reply to this post by j debert
In message <20160716192156.09767350@kendramatic>
jdebert writes:

>
> On Sat, 16 Jul 2016 11:42:44 -0400
> Yuval Levy <[hidden email]> wrote:
>  
> > It is indeed a matter of interpretation, and I would like to see the
> > FCC rules text.  Questions:
> > (1) how do they define "encrypted"?
>  
> The rules and regulations are very clear on what is permitted. They do
> not need to define anything else.
>  
> > (2) on who is the obligation imposed?
>  
> On all licensed amateur radio operators.
>  
> >
> > Imposing the onus on the SMTP server operator is like imposing the
> > onus on gas stations for fueling vehicles used in criminal
> > endeavors.  It does not fly because the gas station can't possibly
> > know what the user will use the vehicle for, other than (probably)
> > driving.
> >
> > By the definition of encryption, an SMTP server operator can't
> > possibly know that a message is encrypted unless the end-user is kind
> > enough to say so, e.g. in the MIME headers.
> >
> >
> > > Don't let them push you down this slippery slope.  If you are
> > > really worried about it, call the FCC or a private attorney and get
> > > a solid interpretation.
> >
> > If I was the SMTP server operator and they came to me, I'd tell them
> > to take a walk.
>  
> The encryption ban dates almost from the earliest days of ham radio. It
> has included unencrypted digital communications formats as well. It has
> been extremely restrictive until recently. The use of ASCII was
> prohibited until recently, for example. Violation of the regulations
> can result in severe fines and forfeiture of license and equipment.
>  
> These are regulations, not laws. There is no due process as there
> may be in criminal cases. It's a completely different legal universe.
> Enforcement of regulations is administrative and not dealt with in the
> courts, until criminal enforcement is necessary.
>  
> Please review part 97 of the FCC regulations, which pertains to amateur
> radio operation. For the FCC's authority, that would be in Title 47 of
> the United States Code.


Way OT but ...

Perhaps check out https://www.tapr.org/ or http://www.arrl.org/ .

My understanding is that packet radio has been allowed in part of the
HAM band and in part of the Marine SSB band for quite a long time.  It
is extremely slow.  In HAM one purpose (as in the purpose of HAM
itself) is experimentation (within constraints) and technical
innovations.  In Marine SSB the purpose is largely safety as it is the
most effient way to get relatively error free detailed weather data
when hundreds or thousands of miles from shore (and one way, though
not the preferred way, to get assistance at sea).

Maybe more technically problematic than the restriction on encryption
is the restriction that the exchange cannot be in any way commercial
and if personal should be extremely brief.  That's a tough filter to
implement.  OTOH - encryption might get you in much deeper trouble.

btw- Unfortunately, a long time ago X.25 was picked.  This has sort of
kept packet radio in the digital stone ages.  BSD dropped X.25 a
decade ago but Linux still has code (marked experimental and does not
seem to be supported).  The ITU has pull in a lot of places so X.25 is
mandated for packet radio in a lot of places.

That said I'm no expert on this (or much of anything :)

Curtis
Reply | Threaded
Open this post in threaded view
|

RE: (OT)Ham Radio + SMTP (was Re: How to restrict encrypted email)

Michael Fox
> My understanding is that packet radio has been allowed in part of the
> HAM band and in part of the Marine SSB band for quite a long time.  
>
> Curtis

That's correct Curtis.  In fact, worldwide electronic mail was possible with
packet and the worldwide BBS network long before commercial Internet email
was available.  And we've been using Postfix to relay between our packet
network and Internet email for years.

AX.25 doesn't really have much to do with it.  It's a reasonable choice for
a link layer protocol for operation over a low-speed, lossy (radio) medium.
That makes it useful in the HF/VHF/UHF bands where channel bandwidth is
limited.  In fact, we run SMTP over AX.25 all the time.

It is really the channel speed, not the link layer protocol, that limits
message size and the use of native email clients and email client protocols
like IMAP, since they are far more chatty than the packet radio protocol for
sending/receiving messages.

But hams also have frequency allocations in the microwave (read WiFi) bands
and can run just as fast as any other commercial product there.  Those high
speed links enable the use of native email clients.  And that drove my
questions about controlling TLS and encryption.

I guess the ON-topic part of this is understanding the reason behind the
need to control the use of TLS and encryption on a client-by-client or
IP-address or other basis.  It's very real and very current, and not just
for "old" or "legacy" stuff.

But, before Wietse kicks me off the list ;-)  please let's get back to
Postfix.  Folks can contact me off list about amateur radio if desired at
n6mef at mefox dot org.

Michael
N6MEF