> On Feb 5, 2017, at 6:49 PM, Jaime Hablutzel Egoavil
> wrote:
>
> Here is one valid use case, the mail service operator
> doesn't manage or participate in the certificate issuance
> itself but he expects that his users get their certificates
> from a commercial CA, e.g. Symantec (which he trus
Sent from my Android device.
On Feb 5, 2017 5:15 PM, "Wietse Venema" wrote:
The answer is simple: because no Postfix access feature currently
requires the info that you're referring to. Lack of demand.
More likely is that the a site allows access based on client
certificates from one trusted si
On Sun, 5 Feb 2017 13:22:22 -0500
Viktor Dukhovni wrote:
> > http://tmp.xaq.nl/postconf.txt
>
> http://www.postfix.org/master.5.html
>
>Chroot (default: Postfix >= 3.0: n, Postfix <3.0: y)
>
> Whether or not the service runs chrooted to the
> mail queue directory (pa
No, all I was saying was that address literals were not currently
processed in the manner you expected. Wietse's patch implements
the (inadvertently) missing feature.
Oh, excellent! That's a easy-to-understand statement.
Thank you.
- James
The answer is simple: because no Postfix access feature currently
requires the info that you're referring to. Lack of demand.
More likely is that the a site allows access based on client
certificates from one trusted signer and in that case, why would
one need the complexity of all the possible na
> On Feb 5, 2017, at 4:44 PM, James wrote:
>
> The original source of my confusion was assuming that all information
> received with the HELO or EHLO command would be processed by the
> smtpd_helo_restrictions.
>
> I understand now that that the text under
> http://www.postfix.org/postconf.5
Thank you for the replies.
The original source of my confusion was assuming that all information received
with the HELO or EHLO command would be processed by the smtpd_helo_restrictions.
I understand now that that the text under
http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions in
Viktor Dukhovni:
>
> > On Feb 5, 2017, at 1:25 PM, James wrote:
> >
> > I guess my basic question here is "does check_helo_access, or
> > check_helo_a_access, play nicely with cidr:table's when the helo/ehlo
> > command presents an address literal?"
>
> Support for cidr tables in check_helo_a
> On Feb 5, 2017, at 1:25 PM, James wrote:
>
> I guess my basic question here is "does check_helo_access, or
> check_helo_a_access, play nicely with cidr:table's when the helo/ehlo command
> presents an address literal?"
Support for cidr tables in check_helo_a_access applies only to domain na
This is a low priority question.
First off: thank you for postfix, it's wonderful. Its common-sense
spam-stopping capabilities are serious overkill for my very modest needs but,
boy, is that overkill ever nice to have.
I guess my basic question here is "does check_helo_access, or check_helo_a
> On Feb 5, 2017, at 12:46 PM, richard lucassen
> wrote:
>
> Uhmm, seeing the output of "postconf -Mf" I think it must be the amavis
> smtpd that runs non-chrooted.
>
> http://tmp.xaq.nl/postconf.txt
http://www.postfix.org/master.5.html
Chroot (default: Postfix >= 3.0: n, Postfix <3.0
On Sun, 5 Feb 2017 12:33:03 -0500
Viktor Dukhovni wrote:
> > I run postfix-3.1.4 with opendkim and opendmarc. These work well,
> > but I just added amavis/SA/clamav and now I get these warnings
> > (everything works well AFAICS). Postfix is chrooted:
>
> Instead of just asserting that "Postfix i
> On Feb 5, 2017, at 10:53 AM, richard lucassen
> wrote:
>
> I run postfix-3.1.4 with opendkim and opendmarc. These work well, but I
> just added amavis/SA/clamav and now I get these warnings (everything
> works well AFAICS). Postfix is chrooted:
Instead of just asserting that "Postfix is chro
I run postfix-3.1.4 with opendkim and opendmarc. These work well, but I
just added amavis/SA/clamav and now I get these warnings (everything
works well AFAICS). Postfix is chrooted:
Feb 5 16:03:57 mail10 postfix/smtpd[2876]: warning: connect to Milter
service unix:/var/run/opendkim/opendkim.sock:
On Sun, 5 Feb 2017 12:44:07 +1300
Peter wrote:
> > http://www.postfix.org/SMTPD_ACCESS_README.html#danger
>
> The issue happens when you have a PERMIT result before other tests
> that you want to run that might result in REJECT. The PERMIT bypasses
> further tests.
>
> There are many solutions
On 05/02/17 16:04, Dominic Raferd wrote:
In contrast a "full service" mailcow install requires 800Mb at the
very least and 1Gb with some usage. Clamav is the real ram killer.
At the risk of going off-topic, is it worth using clamav? I run it
(via amavis) but it last picked up something 'real' 7
On 5 February 2017 at 06:48, Noel Jones wrote:
>
> I keep clam in the mix to use the excellent sanesecurity addon
> signatures. They find lots of spam/phish/ransomware other tools
> miss, with acceptably low false positives.
>
>
Great tip thank you: I've followed it up and am now experimenting
17 matches
Mail list logo
