> On 16 Jul 2016, at 02:50, Lefteris Tsintjelis wrote:
>
> I was thinking it more in simple DNS terms only and a simply reverse
> look up of the IP and then extract the domain from there but it is not
> possible without the FROM.
That wouldn’t have worked anyway.
Assuming a reverse lookup of a
On 16/07/2016 11:35, Jim Reid wrote:
That wouldn’t have worked anyway.
Assuming a reverse lookup of an IP address returns a name -- a big if
-- there’s no guarantee that name has any relation to whatever domain
name is in the MAIL FROM.
For instance, lots of organisations outsource their email
Le 16/07/2016 à 11:11, Lefteris Tsintjelis a écrit :
> On 16/07/2016 11:35, Jim Reid wrote:
>> That wouldn’t have worked anyway.
>>
>> Assuming a reverse lookup of an IP address returns a name -- a big if
>> -- there’s no guarantee that name has any relation to whatever domain
>> name is in the MAI
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
> 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/
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
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
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 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
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
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
(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
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
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
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
> 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
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.
> 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
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.
Moving from a pre-v2.10 to post-v2.10 environment, I'd like make sure I
understand the meaning/context of smtpd_relay_restrictions. Can someone
give me a sanity check?
http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions says:
"By default, the Postfix SMTP server accepts:
* Mail from
20 matches
Mail list logo
