On Tue, Aug 23, 2022 at 01:13:56AM -0400, Demi Marie Obenour wrote:
> You should definitely deploy DNSSEC, but only after you are able to
> deploy it properly. That means having procedures to avoid nasty DNSSEC-
> related downtime.
That's needlessly scary and non-specific. Rather, it means,
On 2022-08-22 Ruben Safir wrote:
> On Mon, Aug 22, 2022 at 08:50:51AM +0200, Ansgar Wiechers wrote:
>> You could use a check_sender_access restriction with a regular
>> expression like this:
>>
>> /bagel/ REJECT
>
> Do I use the map created by the postfix/access file for this?
Depends on your
On 8/22/22 17:38, nate wrote:
> On 2022-08-22 14:30, Viktor Dukhovni wrote:
>
>> Correct, because there's no point. Mail would be sent whether the
>> certificate is trusted or not, and whether or not the DNS-ID matches
>> expectations.
>>
>> Setting up a TLS policy for each domain that's hosted
On Mon, Aug 22, 2022 at 11:42:38PM +0200, Jaroslaw Rafa wrote:
> Hello,
> this just appeared in my Postfix log:
>
> Aug 22 23:35:50 rafa postfix/smtpd[28891]: connect from unknown[unknown]
> Aug 22 23:35:50 rafa postfix/smtpd[28891]: lost connection after CONNECT from
> unknown[unknown]
> Aug 22
On Mon, Aug 22, 2022 at 02:38:20PM -0700, nate wrote:
> On 2022-08-22 14:30, Viktor Dukhovni wrote:
>
> > Correct, because there's no point. Mail would be sent whether the
> > certificate is trusted or not, and whether or not the DNS-ID matches
> > expectations.
> >
> > Setting up a TLS policy
Hello,
this just appeared in my Postfix log:
Aug 22 23:35:50 rafa postfix/smtpd[28891]: connect from unknown[unknown]
Aug 22 23:35:50 rafa postfix/smtpd[28891]: lost connection after CONNECT from
unknown[unknown]
Aug 22 23:35:50 rafa postfix/smtpd[28891]: disconnect from unknown[unknown]
I
On 2022-08-22 14:30, Viktor Dukhovni wrote:
Correct, because there's no point. Mail would be sent whether the
certificate is trusted or not, and whether or not the DNS-ID matches
expectations.
Setting up a TLS policy for each domain that's hosted by Microsoft is
unrealistic, and they don't
On Mon, Aug 22, 2022 at 02:09:26PM -0700, nate wrote:
> postfix/smtp[7329]: Untrusted TLS connection established to
> example-com.mail.protection.outlook.com[104.47.55.110]:25: TLSv1.2 with
> cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>
> I assume it says Untrusted because Postfix
On 2022-08-22 13:55, Viktor Dukhovni wrote:
This should be the full certificate chain, not just the lead
certificate.
For that, you need at least:
smtp_tls_security_level = may
or perhaps (given a local validating resolver and only loopback
nameserver IPs in /etc/resolv.conf or
On Mon, Aug 22, 2022 at 01:41:35PM -0700, nate wrote:
> More recently I formalized this configuration even more in an attempt to
> make my system more up to date, being able to send and receive with
> TLS.
>
> This is my TLS related configuration
> [..]
> smtpd_sasl_tls_security_options =
Dnia 22.08.2022 o godz. 13:41:35 nate pisze:
>
> What I am confused by is Postfix does not appear to be attempting
> to use TLS on any outbound emails. I have tested with Gmail and
> with MS Office 365. Sample tcpdump
Your config contains TLS settings for inbound (stmpd_tls_...) but I don't see
Hello list
Been using postfix for over 20 years now, though haven't really spent
much
time on the SSL end of things for it.
A few years ago I setup SSL for inbound mainly for SASL auth sending
that
has worked fine.
More recently I formalized this configuration even more in an attempt to
On Mon, Aug 22, 2022 at 01:51:59PM -0400, Demi Marie Obenour wrote:
> The correct solution to prevent email forgery is DNSSEC + DKIM +
> DMARC with p=reject + some way to prevent DMARC from accepting based
> on SPF alone. In practice, lots of stuff is misconfigured. I don’t
> run a mail server,
On Mon, Aug 22, 2022 at 08:50:51AM +0200, Ansgar Wiechers wrote:
> On 2022-08-21 Ruben Safir wrote:
> > any way I can block all bagels using access
> >
> > 2022-08-09T22:38:19.695815-04:00 www2 postfix/qmgr[31914]: 2251E16403D:
> > from=,
> > size=9363, nrcpt=1 (queue active)
> >
On 2022-08-22 at 13:18:25 UTC-0400 (Mon, 22 Aug 2022 13:18:25 -0400)
is rumored to have said:
Viktor, genuine question and not meant to be combative;
I feel like I'm forgetting / missing something.
Why isn't every spammer sending spam from <> if it gets a free pass?
As Viktor said,
On 8/22/22 12:17, Phil Stracchino wrote:
> On 8/22/22 11:50, Viktor Dukhovni wrote:
>> On Mon, Aug 22, 2022 at 05:35:54PM +0200, Patrick Proniewski wrote:
>>> But the "loophole" here is that blank sender/return-path is allowed
>>> (MAILER DAEMON), I could prohibit that, but with huge caveats.
>>
On Mon, Aug 22, 2022 at 08:50:51AM +0200, Ansgar Wiechers wrote:
> On 2022-08-21 Ruben Safir wrote:
> > any way I can block all bagels using access
> >
> > 2022-08-09T22:38:19.695815-04:00 www2 postfix/qmgr[31914]: 2251E16403D:
> > from=,
> > size=9363, nrcpt=1 (queue active)
> >
On Mon, Aug 22, 2022 at 01:18:25PM -0400, post...@ptld.com wrote:
> Viktor, genuine question and not meant to be combative;
>
> I feel like I'm forgetting / missing something.
> Why isn't every spammer sending spam from <> if it gets a free pass?
It doesn't get a "free pass", but it correctly
Viktor, genuine question and not meant to be combative;
I feel like I'm forgetting / missing something.
Why isn't every spammer sending spam from <> if it gets a free pass?
On Mon, Aug 22, 2022 at 12:17:52PM -0400, Phil Stracchino wrote:
> A lot of the problems in spam filtering is that the protocols we use for
> email delivery were fundamentally designed in insecure, unauthenticated
> ways, because they were created in a different, friendlier, arguably
> more
On 8/22/22 11:50, Viktor Dukhovni wrote:
On Mon, Aug 22, 2022 at 05:35:54PM +0200, Patrick Proniewski wrote:
But the "loophole" here is that blank sender/return-path is allowed
(MAILER DAEMON), I could prohibit that, but with huge caveats.
Best to ignore bad advice. You may need a better
On Mon, Aug 22, 2022 at 05:35:54PM +0200, Patrick Proniewski wrote:
> > On 22 Aug 2022, at 17:20, post...@ptld.com wrote:
> >
> > This isn't the complete answer to your problem, but one of the puzzle
> > pieces that might help your situation.
> >
> >smtpd_recipient_restrictions =
Hi,
I'm already using:
smtpd_sender_restrictions =
reject_unlisted_sender,
check_sender_access hash:/etc/postfix/sender_access
reject_unknown_sender_domain,
reject_non_fqdn_sender,
permit
But the "loophole" here is that blank sender/return-path is
This isn't the complete answer to your problem, but one of the puzzle pieces
that might help your situation.
smtpd_recipient_restrictions = reject_non_fqdn_sender
http://www.postfix.org/postconf.5.html#reject_non_fqdn_sender
We have received a big batch of phishing emails that was
Hello,
We have received a big batch of phishing emails that was not properly detected
(hence not blocked). They all shared a special characteristic:
To: Recipients
From: Administrateur
Reply-To:
Return-Path: <>
To and From are not qualified email addresses, Reply-To is bogus but qualified
On 2022-08-21 Ruben Safir wrote:
> any way I can block all bagels using access
>
> 2022-08-09T22:38:19.695815-04:00 www2 postfix/qmgr[31914]: 2251E16403D:
> from=,
> size=9363, nrcpt=1 (queue active)
> 2022-08-09T22:39:09.275352-04:00 www2 postfix/qmgr[31914]: ECA0316403D:
> from=,
>
26 matches
Mail list logo
