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 Internet SMTP will not in the next decade
> or two
On Wed, Jul 28, 2021 at 05:58:43AM -0700, Greg Earle
wrote:
> Hello, long time (Courier user) listener, first time (Postfix user) caller
> ...
>
> I'm getting repeated spåms from Brazil and there is no un-sub link.
>
> The sending SMTP servers are various hosts in the *.cnode.io domain, with
On Wed, Jul 28, 2021 at 12:28:25PM +0200, Jean-François Bachelet
wrote:
> Hello Matus ^^)
>
> Le 28/07/2021 à 09:36, Matus UHLAR - fantomas a écrit :
> > On 28.07.21 06:21, Jean-François Bachelet wrote:
> > > I have some problems with my postfix install, will report one by one :
> > >
> > > 1 /
On Thu, Jul 29, 2021 at 12:18:25PM +1000, raf wrote:
> Yes. That's why I said "But that's not going to happen".
> And similarly, port 25 will never be TLS-only. STARTTLS
> isn't going away.
I am less certain that public Internet SMTP will not in the next decade
or two switch to STARTTLS
On Wed, Jul 28, 2021 at 09:21:22PM -0400, Viktor Dukhovni
wrote:
> On Thu, Jul 29, 2021 at 10:26:09AM +1000, raf wrote:
>
> > The only alternative would be to close port 25, use port 465
> > (TLS-only) instead,
>
> This profoundly confuses the SMTP (relay) protocol with the
> SUBMIT
On Wed, Jul 28, 2021 at 01:53:15PM +0200, Jean-François Bachelet
wrote:
> I've tested with 'sendmail' in place of 'postfix' in line 650 and now I get
> a 'fatal error' when sending mails... excert from mail logs sent by
> 'pflogsumm' :
>
> Fatal Errors
>
> sendmail (total: 1)
>
On Wed, Jul 28, 2021 at 01:15:13PM +0200, Jean-François Bachelet
wrote:
> I've tried to concatenate the two lines in one, putting the permit stances
> from line 699 after the line 709 like below
>
> but that don't work either perhaps I should have commented out the line
> 'permit' or put that
On Thu, Jul 29, 2021 at 10:26:09AM +1000, raf wrote:
> The only alternative would be to close port 25, use port 465
> (TLS-only) instead,
This profoundly confuses the SMTP (relay) protocol with the
SUBMIT protocol. MTAs won't EVER send on port 465 or 587.
--
Viktor.
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
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 mounted. On my Debian server, I had to add a
Jim Garrison:
> The simple fix is to create an override file with
>
> systemctl edit postfix.service"
>
> and restore the "After=" dependency on network-online.target
Wietse:
> Thanks. I agree, Postfix should start up after the network is fully
> initialized. That includes all the network
On 7/28/2021 1:49 PM, Wietse Venema wrote:
Jim Garrison:
For anyone encountering this error, I've traced it to a regression of
a very old bug relating to systemd service ordering dependencies.
In my case, OS is CentOS Linux release 8.4.2105
postfix-3.5.8-1.el8.x86_64
Since a recent update
Jim Garrison:
> For anyone encountering this error, I've traced it to a regression of
> a very old bug relating to systemd service ordering dependencies.
>
> In my case, OS is CentOS Linux release 8.4.2105
> postfix-3.5.8-1.el8.x86_64
>
> Since a recent update I've found that, after every
For anyone encountering this error, I've traced it to a regression of
a very old bug relating to systemd service ordering dependencies.
In my case, OS is CentOS Linux release 8.4.2105
postfix-3.5.8-1.el8.x86_64
Since a recent update I've found that, after every reboot, Postfix fails
to start,
On 2021-07-28 11:20:57 -0400, Wietse Venema wrote:
> Vincent Lefevre:
> > I have also noticed that on my server, I had "smtpd_use_tls = yes"
> > from old configuration. But after removing it, the postconf output
> > is changed to
> >
> > smtpd_use_tls = no
> >
> > Is this OK? Shouldn't obsolete
hello benny ^^)
Le 28/07/2021 à 17:06, Benny Pedersen a écrit :
On 2021-07-28 06:21, Jean-François Bachelet wrote:
Hello ^^)
postconf -n is more helpfull
check where root: is deliveing mails to in /etc/mail/aliases
if its delivered to an alias without @ then myorigin in postfix
main.cf
Vincent Lefevre:
[ Charset ISO-8859-1 converted... ]
> On 2021-07-27 01:13:41 -0400, Viktor Dukhovni wrote:
> > > You change to:
> > >
> > >smtpd_enforce_tls = no
> > >smtpd_use_tls = no
> > >smtpd_tls_security_level = may
> >
> > With "smtpd_tls_security_level = may" the obsolete
On July 28, 2021 2:58:21 PM UTC, Viktor Dukhovni
wrote:
>If the postfix-files file does not reflect the content delivered by
>the package, you would typically see errors running "postfix check".
>Either the package should deliver all the files expected upstream,
>or the "postfix-files" file
On 2021-07-27 01:13:41 -0400, Viktor Dukhovni wrote:
> > You change to:
> >
> >smtpd_enforce_tls = no
> >smtpd_use_tls = no
> >smtpd_tls_security_level = may
>
> With "smtpd_tls_security_level = may" the obsolete legacy syntax
> should simply not be used. Just remove the other two
On 2021-07-28 06:21, Jean-François Bachelet wrote:
Hello ^^)
postconf -n is more helpfull
check where root: is deliveing mails to in /etc/mail/aliases
if its delivered to an alias without @ then myorigin in postfix main.cf
will be added before delivering
# example to another system user
If the postfix-files file does not reflect the content delivered by
the package, you would typically see errors running "postfix check".
Either the package should deliver all the files expected upstream,
or the "postfix-files" file should be updated to match the package
content.
--
Viktor.
Hi
imho this is a single case. Enforcing TLS on a public faced smtp port
makes no sense to me. Except if you want to reject quite a bunch of mail :-)
Sure TLS encrypted connections are preferable but to enforce it on an
incoming smtp server is sportive. They would better leave smtpd
encryption
On Wed, Jul 28, 2021 at 04:39:39PM +0200, Josh Good wrote:
> > Subject: Email con TLS inferior a 1.2 / Email with TLS less than 1.2
> >
> > Good Afternoon, We inform you that due to Rhenus security policies,
> > as of 08/01/2021 receiving of emails that do not comply with version
> > 1.2 of the
On 2021-07-26 12:11:16 -0400, Viktor Dukhovni wrote:
[...]
> At which point the only files in /etc/postfix that are updated with
> each package release are:
>
> $config_directory/LICENSE:f:root:-:644:1
> $config_directory/TLS_LICENSE:f:root:-:644:1
>
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 June 2021 17:05
> To: [omitted]
> Subject: Email con TLS inferior
On Wed, Jul 28, 2021 at 05:58:43AM -0700, Greg Earle wrote:
> [root@isolar postfix]# grep -n sender_access master.cf
> 27: -o mua_sender_restrictions= permit_sasl_authenticated,
> reject_unknown_reverse_client_hostname, reject_unknown_client_hostname,
> reject_unknown_sender_domain,
On 2021-07-28 at 07:15:13 UTC-0400 (Wed, 28 Jul 2021 13:15:13 +0200)
Jean-François Bachelet
is rumored to have said:
[...]
I've tried to concatenate the two lines in one, putting the permit
stances from line 699 after the line 709 like below
but that don't work either perhaps I should have
On 28.07.21 05:58, Greg Earle wrote:
I'm getting repeated spåms from Brazil and there is no un-sub link.
The sending SMTP servers are various hosts in the *.cnode.io domain,
with different subnets involved so trying to block them all is like
playing Whack-a-Mole™. They also like to change up
Hello, long time (Courier user) listener, first time (Postfix user)
caller ...
I'm getting repeated spåms from Brazil and there is no un-sub link.
The sending SMTP servers are various hosts in the *.cnode.io domain,
with different subnets involved so trying to block them all is like
playing
Le 28/07/2021 à 13:15, Jean-François Bachelet a écrit :
Hello raf ^^)
Le 28/07/2021 à 08:54, raf a écrit :
On Wed, Jul 28, 2021 at 06:21:55AM +0200, Jean-François Bachelet
wrote:
Hello ^^)
I have some problems with my postfix install, will report one by one :
Thanks by advance to
Hello raf ^^)
Le 28/07/2021 à 08:54, raf a écrit :
On Wed, Jul 28, 2021 at 06:21:55AM +0200, Jean-François Bachelet
wrote:
Hello ^^)
I have some problems with my postfix install, will report one by one :
I have activated the 'soft_bounce = yes' option in main.cf to see what
happens.
1
Le 28/07/2021 à 09:36, Matus UHLAR - fantomas a écrit :
this mean that your server is going to send mail to "server.mydomain.com"
and your postfix sees it should deliver domain to itself, but
postfix does
not know how to handle mail for server.mydomain.com
- you have to put
Hello Matus ^^)
Le 28/07/2021 à 09:36, Matus UHLAR - fantomas a écrit :
On 28.07.21 06:21, Jean-François Bachelet wrote:
I have some problems with my postfix install, will report one by one :
I have activated the 'soft_bounce = yes' option in main.cf to see
what happens.
1 / Mail sent
On 28.07.21 06:21, Jean-François Bachelet wrote:
I have some problems with my postfix install, will report one by one :
I have activated the 'soft_bounce = yes' option in main.cf to see what
happens.
1 / Mail sent by some daemons running as 'root' (here it's Pflogsumm,
per example) with
On Wed, Jul 28, 2021 at 06:21:55AM +0200, Jean-François Bachelet
wrote:
> Hello ^^)
>
> I have some problems with my postfix install, will report one by one :
>
> I have activated the 'soft_bounce = yes' option in main.cf to see what
> happens.
>
>
> 1 / Mail sent by some daemons running as
35 matches
Mail list logo
