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
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
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
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
> 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
20 matches
Mail list logo
