On 2023-08-15 at 21:52:52 UTC-0400 (Tue, 15 Aug 2023 21:52:52 -0400)
Alex via Postfix-users
is rumored to have said:
[...]
Yes, it is a loop. The loop occurs inside MS365. Apparently Microsoft
does not understand how to get mail from CompanyA to CompanyB
internally, so they follow the DNS.
b
>
>
> On August 15, 2023 2:15:21 AM GMT+02:00, Jon Smart via Postfix-users
> wrote:
>>Hello,
>>
>>I have disabled port 587/465 to be accessed publicly.
>>
>>but port 25 must be open to internet for MTA communications.
>>
>>My question is, can external users access port 25 for smtp auth and send
>>
Hi,
On Tue, Aug 15, 2023 at 8:49 AM Bill Cole via Postfix-users <
postfix-users@postfix.org> wrote:
> On 2023-08-14 at 17:23:34 UTC-0400 (Mon, 14 Aug 2023 17:23:34 -0400)
> Alex via Postfix-users
> is rumored to have said:
>
> > Hi,
> > I have what appears to be a complicated mail loop problem t
Hi,
On Tue, Aug 15, 2023 at 11:53 AM Paul Enlund via Postfix-users <
postfix-users@postfix.org> wrote:
> Hi
>
> One thing to check is that your MX server allowed recipients is in sync
> with M365 allowed recipients.
>
Can you explain more of what you mean here? In this case, the recipient
does ex
Hi,
On Tue, Aug 15, 2023 at 11:02 AM Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
> Your loop, based on Received: headers, newer at the top, older at
> the bottom:
>
> Received: from xavier.example.com (209.216.111.114) by
> CO1PEPF44F7.mail.protection.outlook.com (10.1
On Wed, Aug 16, 2023 at 01:51:24AM +0200, Étienne Miret via Postfix-users wrote:
> I found this discrepancy surprising and am suggesting it is removed. In
> case others argue it is useful or that removing it will break some
> configurations, I am asking it is documented.
The discrepancy is inte
Hello,
Did you mean command-line submission with /usr/sbin/sendmail?
Yes, as well as internal submission by a Postfix process when using
aliasing. Sorry, I thought I was explicit (albeit the typo in "command").
This will receive and then bounce the message.
Nope. My tests (using the Debi
On Tue, Aug 15, 2023 at 05:12:53PM -0400, Viktor Dukhovni via Postfix-users
wrote:
> > 2023-08-14T13:12:00.131049-04:00 svr01
> > postfix/postscreen-internal/smtpd[27907]: disconnect from
> > mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]
> > ehlo=1 starttls=1 quit=1 co
?tienne Miret via Postfix-users:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Hello,
>
> After troubleshooting an issue on my Postfix server, I found out that
> the local_recipient_maps parameter is ignored for locally submitted
> emails. That is, a recipient no
Hello,
After troubleshooting an issue on my Postfix server, I found out that
the local_recipient_maps parameter is ignored for locally submitted
emails. That is, a recipient not listed there will:
- be rejected for mail received from the Internet,
- still get mails from the sendmail commnd a
OK mail from outlook does make it's way thru; e.g., since Monday,
xzegrep "250 2.0.0 Queued as.*outbound.protection.outlook.com"
/var/log/postfix/postfix.log | wc -l
4343
Isn't that outbound mail*to* Microsoft-hosted domains? I wouldn't
expect that to appear in logs of incoming ma
There is no protection you can add to prevent this
fair enuf
other than firewalling them completely.
the wishful-thinking of fw'ing MS's entire ASN has crossed my mind more than
once ;-)
Why do they do this? Only they know.
if they do, they certainly don't respond to @support/etc inqui
On Tue, Aug 15, 2023 at 04:14:58PM -0400, pgnd via Postfix-users wrote:
> 2023-08-14T13:11:53.782611-04:00 svr01 postfix/postscreen[27910]: CONNECT
> from [52.101.56.17]:32607 to [209.123.234.54]:25
> 2023-08-14T13:11:59.860098-04:00 svr01 postfix/postscreen[27910]: PASS NEW
> [52.101.56.17]:326
On 8/15/2023 3:14 PM, pgnd via Postfix-users wrote:
my "BFFs" @ M$'s *.outlook.com have decided over the last month or
so to send many 10K's of these
2023-08-14T13:11:53.782611-04:00 svr01
postfix/postscreen[27910]: CONNECT from [52.101.56.17]:32607 to
[209.123.234.54]:25
2023-08-14
my "BFFs" @ M$'s *.outlook.com have decided over the last month or so to send
many 10K's of these
2023-08-14T13:11:53.782611-04:00 svr01 postfix/postscreen[27910]:
CONNECT from [52.101.56.17]:32607 to [209.123.234.54]:25
2023-08-14T13:11:59.860098-04:00 svr01 postfix/postscreen[
Viktor Dukhovni via Postfix-users:
> On Tue, Aug 15, 2023 at 11:33:08AM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > With that, the condition evaluates to:
> >
> > 1: session->tls_context == 0 true
> > 2: state->tls->level == TLS_LEV_MAYpresumably t
On Tue, Aug 15, 2023 at 11:51:07AM -0400, Wietse Venema via Postfix-users wrote:
> > That's my instinct also. Waiting out transient glitches by retrying on
> > the next delivery attempt is not an option for probes. And probes don't
> > leak message content in the clear, nor even the full envelop
Hi
One thing to check is that your MX server allowed recipients is in sync
with M365 allowed recipients.
Regards Paul
On 14/08/2023 22:23, Alex via Postfix-users wrote:
Hi,
I have what appears to be a complicated mail loop problem that I can't
figure out. I suspect that their receiving syst
Viktor Dukhovni via Postfix-users:
> On Tue, Aug 15, 2023 at 11:33:08AM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > With that, the condition evaluates to:
> >
> > 1: session->tls_context == 0 true
> > 2: state->tls->level == TLS_LEV_MAYpresumably t
Well, in my case this is recipient verification - I am sending abuse complaints
in bulk and to eliminate tons of email bounces I have enabled address
verification.
On 8/15/23 15:43, Viktor Dukhovni via Postfix-users wrote:
So it seems that legitimate domains (from which one actually cares to
r
On Tue, Aug 15, 2023 at 11:33:08AM -0400, Wietse Venema via Postfix-users wrote:
> With that, the condition evaluates to:
>
> 1: session->tls_context == 0 true
> 2: state->tls->level == TLS_LEV_MAYpresumably true
> 3: PREACTIVE_DELAY >= var_min_backoff_ti
Viktor Dukhovni via Postfix-users:
> > > Aug 15 12:22:18 flopster postfix/cleanup[9839]: 5058916E081A:
> > > message-id=<20230815092218.5058916e0...@flopster.at.encryp.ch>
> > > Aug 15 12:22:18 flopster postfix/qmgr[11478]: 5058916E081A:
> > > from=, size=316, nrcpt=1 (queue active)
> > > Aug 15
On 8/15/23 14:49, Viktor Dukhovni via Postfix-users wrote:
smtp_tls_loglevel = 0
Level 1 is typically more informative at negligible additional cost.
I have set this option and tried to send email once again:
Aug 15 18:11:48 flopster postfix/smtp[6025]: warning: TLS library problem:
error
Your loop, based on Received: headers, newer at the top, older at
the bottom:
Received: from xavier.example.com (209.216.111.114) by
CO1PEPF44F7.mail.protection.outlook.com (10.167.241.197) with Microsoft S
Received: from localhost by xavier.example.com (Postfix) with ESMTP id
30B17305F4A07;
[ $subject would have been more clear had the OP mentioned that he's
talking about address verification probes. ]
On Tue, Aug 15, 2023 at 01:29:14PM +, Serg via Postfix-users wrote:
> > admin@flopster ~ $ sudo postconf | grep ^smtp_tls
> > smtp_tls_cert_file = /etc/ssl/domains/flopster.at.e
Hello,
I have following configuration applied:
admin@flopster ~ $ sudo postconf | grep ^smtp_tls
smtp_tls_CAfile =
smtp_tls_CApath =
smtp_tls_block_early_mail_reply = no
smtp_tls_cert_file = /etc/ssl/domains/flopster.at.encryp.ch/fullchain
smtp_tls_chain_files =
smtp_tls_ciphers = medium
smtp_t
On 2023-08-14 at 15:13:54 UTC-0400 (Mon, 14 Aug 2023 16:13:54 -0300)
SysAdmin EM via Postfix-users
is rumored to have said:
Hi, Is it possible to discard an email based on the Subject and the
destination email address?
I try this and not work:
/^Subject:.*Test email subject .*To:.*m...@me.com
On 2023-08-14 at 17:23:34 UTC-0400 (Mon, 14 Aug 2023 17:23:34 -0400)
Alex via Postfix-users
is rumored to have said:
Hi,
I have what appears to be a complicated mail loop problem that I can't
figure out. I suspect that their receiving system (M365) is somehow
reinjecting the message back to our
* Benny Pedersen via Postfix-users [230815 05:10]:
> Peter via Postfix-users skrev den 2023-08-15 10:44:
>
> > This is a bad idea for several reasons. If you want submission use
> > ports 465 and/or 587 as they are intended. Don't try to use a service
> > that is meant for a different purpose f
Peter via Postfix-users skrev den 2023-08-15 10:44:
This is a bad idea for several reasons. If you want submission use
ports 465 and/or 587 as they are intended. Don't try to use a service
that is meant for a different purpose for this.
mta to mta can use port 465 or 587 aswell for intended
On 15/08/23 12:15, Jon Smart via Postfix-users wrote:
I have disabled port 587/465 to be accessed publicly.
These are the submission and submissions ports, for user submission of mail.
but port 25 must be open to internet for MTA communications.
Port 25 is for MX to MX communication, for a
On August 15, 2023 2:15:21 AM GMT+02:00, Jon Smart via Postfix-users
wrote:
>Hello,
>
>I have disabled port 587/465 to be accessed publicly.
>
>but port 25 must be open to internet for MTA communications.
>
>My question is, can external users access port 25 for smtp auth and send
>mail then?
N
On August 15, 2023 7:05:32 AM GMT+02:00, Chad Lundquist via Postfix-users
wrote:
>I am getting legitimate emails REJECTED by postfix and I need to figure out a
>way to forward them or whitelist them from getting blocked.
>
>
>
>I am using PFLogsumm and see this:
>
>
>
>message reject detail
33 matches
Mail list logo
