> 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 Interne
In message <20160716192156.09767350@kendramatic>
jdebert writes:
>
> On Sat, 16 Jul 2016 11:42:44 -0400
> Yuval Levy 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 regu
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 you
On Sat, 16 Jul 2016 11:42:44 -0400
Yuval Levy 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.
> 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
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.
> On Jul 16, 2016, at 11:11, Erwan David 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
>>> doe
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
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 th
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 (prob
(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 STA
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 contai
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 ta
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
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
>> -
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, se
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 r
> 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/
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 t
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, he
20 matches
Mail list logo
