On 7/29/2021 12:34 AM, Matus UHLAR - fantomas wrote:
On 28.07.21 12:54, Jim Garrison wrote:
This means that Postfix now starts up before the network is completely
up, and systemd's DNS resolution hack (systemd-resolved.service),
finding no interfaces up yet, resolves 'localhost' to 127.0.0.2.
Sean McBride:
> On Thu, 29 Jul 2021 22:17:49 +1000, raf said:
>
> >That second sentence sounds to me like a definite
> >statement that an SMTP connection that doesn't initiate
> >STARTTLS will not be able to send email. At least, I
> >can't see how else to interpret those words.
>
> Which is an
On Thu, 29 Jul 2021 22:17:49 +1000, raf said:
>That second sentence sounds to me like a definite
>statement that an SMTP connection that doesn't initiate
>STARTTLS will not be able to send email. At least, I
>can't see how else to interpret those words.
Which is an odd thing considering,
Wietse Venema:
> AFTER the message is received, the message size is known.
Thanks, Wietse. Makes sense now. Like this it works:
smtpd_recipient_restrictions = reject_unauth_destination
smtpd_end_of_data_restrictions = \
check_policy_service inet:localhost:12340
It's just a bit wasteful
Wietse Venema:
> Christoph Haas:
> > request=smtpd_access_policy
> > protocol_state=RCPT
> ...
> > size=0
>
> The RCPT TO command is received before the message is
> received, therefore the message size is not known.
Also, the client did not specify a message size when it sent the
MAIL FROM
Christoph Haas:
> request=smtpd_access_policy
> protocol_state=RCPT
...
> size=0
The RCPT TO command is received before the message is
received, therefore the message size is not known.
> My Postfix log shows though:
>
> postfix/qmgr[43700]: A031B9D69C: from=, size=501,
> nrcpt=1 (queue
Dear list,
I'm chasing a strange phenomenon with Postfix 3.5.6. I deliver virtual
emails through LMTP to Dovecot. That works well. Now I'd also like to
check the user's quota using Dovecot's quota service as described at
https://doc.dovecot.org/configuration_manual/quota_plugin/#quota-service
Le 29/07/2021 à 18:46, Dominic Raferd a écrit :
> Some commercial vulnerability scan services (e.g. by Qualys,
> SecurityMetrics) which are required by payment providers regard
> TLSv1/TLSv1.1 as absolute fails for PCI DSS compliance and
> organisations that must meet PCI DSS
>
> On 29 Jul 2021, at 12:46 pm, Dominic Raferd wrote:
>
> Some commercial vulnerability scan services (e.g. by Qualys, SecurityMetrics)
> which are required by payment providers regard TLSv1/TLSv1.1 as absolute
> fails for PCI DSS compliance and organisations that must meet PCI DSS
>
On 29/07/2021 17:24, Josh Good wrote:
On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:
On 29 Jul 2021, at 8:17 am, raf wrote:
The Rhenus email did say:
"...must be sent with the TLS 1.2 protocol or higher.
Any mail received without fulfilling this condition
will be rejected by our
On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:
> > On 29 Jul 2021, at 8:17 am, raf wrote:
> >
> > The Rhenus email did say:
> >
> > "...must be sent with the TLS 1.2 protocol or higher.
> > Any mail received without fulfilling this condition
> > will be rejected by our server."
> >
> > That
> On 29 Jul 2021, at 8:17 am, raf wrote:
>
> The Rhenus email did say:
>
> "...must be sent with the TLS 1.2 protocol or higher.
> Any mail received without fulfilling this condition
> will be rejected by our server."
>
> That second sentence sounds to me like a definite
> statement that
Vincent Lefevre:
> On 2021-07-29 10:54:11 +0200, Daniele Nicolodi wrote:
> > On 29/07/2021 00:17, Vincent Lefevre wrote:
> > > On 2021-07-28 16:49:20 -0400, Wietse Venema wrote:
> > >> Thanks. I agree, Postfix should start up after the network is fully
> > >> initialized. That includes all the
On 2021-07-29 10:54:11 +0200, Daniele Nicolodi wrote:
> On 29/07/2021 00:17, Vincent Lefevre wrote:
> > On 2021-07-28 16:49:20 -0400, Wietse Venema wrote:
> >> Thanks. I agree, Postfix should start up after the network is fully
> >> initialized. That includes all the network interfaces, and all
Wietse Venema:
> Wietse Venema:
> > Jaroslav Skarvada:
> > > Hi,
> > >
> > > glibc-2.34 introduced the closefrom function which causes postfix build
> > > to fail:
> > >
> > > In file included from ./vstream.h:22,
> > > from attr_print64.c:100:
> > >
Wietse Venema:
> Jaroslav Skarvada:
> > Hi,
> >
> > glibc-2.34 introduced the closefrom function which causes postfix build to
> > fail:
> >
> > In file included from ./vstream.h:22,
> > from attr_print64.c:100:
> > /usr/include/unistd.h:363:13: error: conflicting types for
On Thu, Jul 29, 2021 at 09:13:39AM +0200, Josh Good
wrote:
> Well, it's not exactly clear, in the Rhenus notification, whether they
> are just disabling TLS 1.0, or that plus also disabling plain text SMTP.
>
> Viktor thinks it's just the first case. But we should not underestimate
> the push
On Thu, Jul 29, 2021 at 10:37:46AM +0200, Matus UHLAR - fantomas
wrote:
> On 29.07.21 10:26, raf wrote:
>
> > On my little personal mail server, 75% of incoming
> > connections to port 25 are plaintext. Only 25% use
> > STARTTLS (by definition). Disabling STARTTLS would
> > be a disaster, and
Jaroslav Skarvada:
> Hi,
>
> glibc-2.34 introduced the closefrom function which causes postfix build to
> fail:
>
> In file included from ./vstream.h:22,
> from attr_print64.c:100:
> /usr/include/unistd.h:363:13: error: conflicting types for 'closefrom'; have
> 'vo
> 363 |
Dnia 29.07.2021 o godz. 12:26:49 Tobi pisze:
>
> Just take the case when they loose a huge customer order because
> customer still operates an Exchange 2003 server, which by best can talk
> TLS 1.0. Then Management will soon show up in IT department and highly
> probably ignore the fact that it
Josh,
On 7/29/21 9:13 AM, Josh Good wrote:
> Well, it's not exactly clear, in the Rhenus notification, whether they
> are just disabling TLS 1.0, or that plus also disabling plain text SMTP.
>
> Viktor thinks it's just the first case. But we should not underestimate
> the push that a
On 29/07/2021 00:17, Vincent Lefevre wrote:
> On 2021-07-28 16:49:20 -0400, Wietse Venema wrote:
>> Thanks. I agree, Postfix should start up after the network is fully
>> initialized. That includes all the network interfaces, and all the
>> network infrastructure services.
>
> And the disks are
On Wed, Jul 28, 2021 at 04:39:39PM +0200, Josh Good
wrote:
Hello everybody.
I've been made aware of this communication recently received at some
site whose email is managed on-premises (i.e., not outsourced to any
big mailbox provider in the "cloud"):
> From: Rhenus Logistics
> Sent: 30
Hi,
glibc-2.34 introduced the closefrom function which causes postfix build to fail:
In file included from ./vstream.h:22,
from attr_print64.c:100:
/usr/include/unistd.h:363:13: error: conflicting types for 'closefrom'; have 'vo
363 | extern void closefrom (int __lowfd)
On 28.07.21 12:54, Jim Garrison wrote:
This means that Postfix now starts up before the network is completely
up, and systemd's DNS resolution hack (systemd-resolved.service),
finding no interfaces up yet, resolves 'localhost' to 127.0.0.2.
(man systemd-resolved.service)
sorry, but this
On 2021 Jul 29, 15:48, raf wrote:
> On Wed, Jul 28, 2021 at 11:20:03PM -0400, Viktor Dukhovni
> wrote:
>
> > On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
> >
> > > And similarly, port 25 will never be TLS-only. STARTTLS
> > > isn't going away.
> >
> > I am less certain that public
Sounds like requirement from some security audit..
Eero
On Thu, Jul 29, 2021 at 8:49 AM raf wrote:
> On Wed, Jul 28, 2021 at 11:20:03PM -0400, Viktor Dukhovni <
> postfix-us...@dukhovni.org> wrote:
>
> > On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
> >
> > > And similarly, port 25 will
27 matches
Mail list logo
