Thank you so much for the in-depth response!!
On 2/6/25 7:10 PM, Wietse Venema via Postfix-users wrote:
You should not prepend the header with multi-recipient deliveries,
because that is a privacy problem.
I wonder, what happens with your config in this case? Would it omit the
X-Original-To
Ellie via Postfix-users:
> Dear postfix users community,
>
> Sorry for asking another beginner question. I've seen solutions online
> for this, but only one with caveats.
>
> One of my setups involves a forwarding SMTP that handles external
> domains, that then f
Dear postfix users community,
Sorry for asking another beginner question. I've seen solutions online
for this, but only one with caveats.
One of my setups involves a forwarding SMTP that handles external
domains, that then forwards them to some other internal mailbox on a
different ma
That‘s great news. Happy to see that Postfix isn’t just maintained but rather
steadily developing.
Have a nice evening!
Ömer
> Am 05.02.2025 um 21:00 schrieb Wietse Venema via Postfix-users
> :
>
>
>>
>> What do you think about the other one?
>> Not fo
e of no TLS).
We already have the technical nuts and bolts for all of the above,
we just need to provide a 'happy path'(*) for easy adoption.
Like Postfix, Viktor's $WORK is in a code freeze, so we'll continue
the discussion later.
(While implementing RFC 8689 REQUIRETLS whi
:53 schrieb Wietse Venema via Postfix-users
> :
>
> ?mer G?ven via Postfix-users:
>> Hi!
>>
>> For the next release (3.10), I'd like to propose that unknown tags
>> returned by TLS policy socketmap servers are logged as warnings,
>> but never regarded a
?mer G?ven via Postfix-users:
> Hi!
>
> For the next release (3.10), I'd like to propose that unknown tags
> returned by TLS policy socketmap servers are logged as warnings,
> but never regarded as an invalid policy. This would avoid delivery
> errors introduced by fu
Hi!
For the next release (3.10), I‘d like to propose that unknown tags returned by
TLS policy socketmap servers are logged as warnings, but never regarded as an
invalid policy.
This would avoid delivery errors introduced by future additions, when an older
Postfix version doesn‘t support a tag
On 2/5/25 5:57 PM, Wietse Venema via Postfix-users wrote:
The following is now part of Postfix 3.10, which is back in the
code freeze stage.
Thank you so much for working on this, this is amazing!!
Regards,
ell1e
___
Postfix-users mailing list
The following is now part of Postfix 3.10, which is back in the
code freeze stage.
Wietse
smtpd_hide_client_session (default: no)
Do not include SMTP client session information in the Postfix SMTP
server's Received: message header.
o The default se
On Wed, Feb 05, 2025 at 15:31:44 +0100, Ömer Güven via Postfix-users wrote:
> At least the big companies like GMail never complained about it, the
> Authenticated Received Chain (ARC) always passes without errors, even
> for forwarding. :-)
Yes, the message is still RFC 5322 compliant,
At least the big companies like GMail never complained about it, the
Authenticated Received Chain (ARC) always passes without errors, even for
forwarding. :-)
> Am 05.02.2025 um 15:28 schrieb Geert Hendrickx via Postfix-users
> :
>
> On Wed, Feb 05, 2025 at 14:58:48 +0100, Öm
On Wed, Feb 05, 2025 at 14:58:48 +0100, Ömer Güven via Postfix-users wrote:
> My solution does completely remove the Received header, so that the
> next-hop adds an appropriate one, usually pointing to the sending MX‘
> ip address.
Which is also not RFC 5321 compliant, just not v
Geert Hendrickx via Postfix-users:
> On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote:
> > This reduces the Received: header from:
> >
> > Received: from
> > by servername (Postfix) with id yyy; server-date-stamp
> &g
On Wed, Feb 05, 2025 at 02:01:27PM +0100, Geert Hendrickx via Postfix-users
wrote:
> It seems that such reduced Received header would not be RFC5321 compliant,
> as the "from " clause is mandatory according to section 4.4.
It is still a valid Received header, just like t
ert Hendrickx via Postfix-users
> :
> On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users
> wrote:
>> This reduces the Received: header from:
>>
>>Received: from
>>by servername (Postfix) with id yyy; server-date-stamp
>>
On Tue, Feb 04, 2025 at 17:09:52 -0500, Wietse Venema via Postfix-users wrote:
> This reduces the Received: header from:
>
> Received: from
> by servername (Postfix) with id yyy; server-date-stamp
>
> to:
>
> Received: by servername (Postfix)
On Wed, 5 Feb 2025 at 11:06, Allen Coates via Postfix-users <
postfix-users@postfix.org> wrote:
>
> In my access lists I have found that 0.0.0.0/0 matches every IPv4
> address, and ::/0 matches every IPv6 address.
>
> (Unless, of course you are expressly testing for a spec
On 05/02/2025 10:50, Gilgongo via Postfix-users wrote:
>
> And have the following in my access file:
>
> user1 192.x.x.x PERMIT
> user1 2001:x:x:x::x PERMIT
> user1 REJECT
>
>
In my access lists I have found that 0.0.0.0/0 matches every IPv4 address,
xample would the following be valid?
user-1 192.x.x.1 OK
user-1 2001:x:x:x::AB OK
user-1 2001:x:x:x:: REJECT
user-1 192.x.x REJECT
That is, using a multi-line rule?
_______
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
n - n- - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sender_restrictions=
-o smtpd_milters=
-o { smtpd_client_restrictions=
check_sasl_access hash:/etc/postfix/sasl_access
}
-o { smtpd_recipient_restrictions=
reje
Oops, sorry. My initial mail was sent 6 hours ago, but I forgot to Reply-All.
Meanwhile, there is already another solution provided.
Ömer
> Am 05.02.2025 um 08:19 schrieb Ömer Güven via Postfix-users
> :
>
>
> Hi!
>
> I didn‘t read the whole thread but I understand t
file:
submission-header-cleanup unix n - n- 0 cleanup
-o header_checks=regexp:/etc/postfix/submission_header_cleanup
Now create the file submission_header_cleanup:
/^Received:/IGNORE
/^X-Originating-IP:/IGNORE
/^X-Mailer:/IGNORE
/^User-Agent
On Tue, Feb 04, 2025 at 05:09:52PM -0500, Wietse Venema via Postfix-users wrote:
> I will implement Ellie's request, and move the Postfix 3.10 code
> freeze up by a few days.
>
> smtpd_hide_session_info (default: no)
>
> Hide SMTP session info from the Received: message
MILTER protocol instead?
Florian
Am 04.02.2025 um 23:09 schrieb Wietse Venema via Postfix-users:
ellie via Postfix-users:
I sent a test mail to a throwaway account now, and found the according
log entry! The one you wanted was gone since I happened to have reboot
with wiped logs since then. I hope
On Tue, Feb 04, 2025 at 08:17:08PM -0500, postfix--- via Postfix-users wrote:
> > If the intent is to only censor submission, This is not correct, it will
> > drop all "Received" headers from any mail that is not delivered locally,
> > so entirely unsuitable for
ed locally.
Yes, this is what I meant, sorry I didn't word it better or acknowledge
there's more than one way to get an email "in" other than submission. "leaves
the system" is what i meant when saying "on its way out to the world".
On Tue, Feb 04, 2025 at 06:29:47PM -0500, postfix--- via Postfix-users wrote:
> I might have misunderstood the point of this as im jumping in late, but
> there is both `header_checks` and `smtp_header_checks`.
> Normal header checks get applied to (smtpd) mail being received on port 25
-o { smtp_header_checks = pcre:{{/^Received:/ IGNORE}} }
I don't know if that is valid syntax. It might need to be done in main
instead of master. Not every postfix setting works in master.
Hopeful someone more knowledgeable can st
On 2/5/25 12:29 AM, postfix--- via Postfix-users wrote:
I might have misunderstood the point of this as im jumping in late, but
there is both `header_checks` and `smtp_header_checks`.
That seems very promising, I tried to put it into practice right now:
smtp inet n - n - - smtpd
-o
smtpd_hide_session_info (default: no)
Hide SMTP session info from the Received: message header. Do not
record the SMTP client name or IP address, SASL login name, or TLS
session details. This reduces the Received: header from:
Received: from
by servername (Postfix) with id
ellie via Postfix-users:
> I sent a test mail to a throwaway account now, and found the according
> log entry! The one you wanted was gone since I happened to have reboot
> with wiped logs since then. I hope it shows something helpful :-o sorry
> again for the effort.
OK, so I ha
On 2/4/25 19:48, Wietse Venema via Postfix-users wrote:
What did Postfox log at 18:06:46 - postfix/submission/smtpd or postfix/smtpd?
Wietse
I sent a test mail to a throwaway account now, and found the according
log entry! The one you wanted was gone since I happened to have reboot
Ellie via Postfix-users:
> Yet "Received" still seems present in full, you can see it with this
> e-mail I'm typing in this moment.
Received: from [10.42.0.75]
(dynamic-176-003-178-138.176.3.pool.telefonica.de
[176.3.178.138])
by mail.ekda
On 2/4/25 7:07 PM, Ellie via Postfix-users wrote:
Sorry for me perhaps bugging this again! I pondered how I could possibly
be using the wrong file, but I can't think of anything.
To rule out that pcre is the issue, I installed all versions of pcre and
pcre2 both 16 and 32 that Alpine
On 2/4/25 7:00 PM, Wietse Venema via Postfix-users wrote:
You forgot to "postfix reload", or you edited the wrong master.cf
file.
What is the output from:
postconf -Mf submission/inet
It should show the new header_checks setting.
These master.cf sttings override main.cf so
Ellie via Postfix-users:
> On 2/4/25 4:50 PM, Wietse Venema via Postfix-users wrote:
> > Yes you did. You forgot to start line 16 with a space or tab.
> >
> > Wietse
> Oops, how silly, sorry! Okay, I think I got it:
>
> smtp inet n - n - - smtpd
>-o
Viktor Dukhovni via Postfix-users:
> On Mon, Feb 03, 2025 at 05:56:45PM -0500, Wietse Venema via Postfix-users
> wrote:
>
> > There is no built-in featrue to delete IP addresses from headers.
>
> But, given the expected header form, it is not difficult to craft a PCRE
>
On 2/4/25 4:50 PM, Wietse Venema via Postfix-users wrote:
Yes you did. You forgot to start line 16 with a space or tab.
Wietse
Oops, how silly, sorry! Okay, I think I got it:
smtp inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o { header_checks=regexp:/etc/postfix
Ellie via Postfix-users:
> mail-1 | /usr/sbin/postconf: fatal: file /etc/postfix/master.cf: line
> 16: bad field count
>
> (Sorry if I did something super obvious wrong!)
Yes you did. You forgot to start line 16 with a space or tab.
On 2025-02-03 at 21:55:14 UTC-0500 (Tue, 4 Feb 2025 03:55:14 +0100)
Ellie via Postfix-users
is rumored to have said:
On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
If this is for messages submitted on port 587 (submission) or 465
(smtps or submissions), then you can simply delete
On 2/4/25 4:15 AM, Wietse Venema via Postfix-users wrote:
Ellie via Postfix-users:
The submission configurations as distributed have
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
which will reject mail without SASL login.
Wietse
Thank you so much for the
On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
master.cf:
submission .. .. .. .. .. .. .. smtpd
-o { header_checks = pcre:{{/^Received:/ IGNORE}} }
...other -o options...
submissions .. .. .. .. .. .. .. smtpd
-o { header_checks = pcre
Ellie via Postfix-users:
> On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
> > If this is for messages submitted on port 587 (submission) or 465
> > (smtps or submissions), then you can simply delete all Received:
> > message headers, because there shuold be only
On 2/4/25 2:25 AM, Viktor Dukhovni via Postfix-users wrote:
Though one might want to be prepared to encounter more friction for
outbound mail lacking all upstream Received headers. These tend to
be classed more "spammy".
This made me curious, and I've checked a bunch of inco
On 2/3/25 11:56 PM, Wietse Venema via Postfix-users wrote:
If this is for messages submitted on port 587 (submission) or 465
(smtps or submissions), then you can simply delete all Received:
message headers, because there shuold be only one.
Thanks so much for your helpful response! I wonder
On Mon, Feb 03, 2025 at 05:56:45PM -0500, Wietse Venema via Postfix-users wrote:
> There is no built-in featrue to delete IP addresses from headers.
But, given the expected header form, it is not difficult to craft a PCRE
table that does the job well.
> If this is for messages submitted o
Ellie via Postfix-users:
> Dear postfix users group,
>
> Sorry if this is the wrong place to ask, or if this is a nonsensical
> question.
>
> But it seems to me that discarding the exact end-user device IP from
> e-mails sent via any authenticated path is going to be a
Dear postfix users group,
Sorry if this is the wrong place to ask, or if this is a nonsensical
question.
But it seems to me that discarding the exact end-user device IP from
e-mails sent via any authenticated path is going to be a common scenario
in today's more privacy aware age.
Ye
On 4/02/25 09:53, Emmanuel Seyman via Postfix-users wrote:
* Josh Good via Postfix-users [31/01/2025 00:37] :
There were community-provided RPM packages of Postfix for Red Hat 6.2
(Classic), as noted in the original post for this thread, but none of
them seems to have survived on any publicly
Bill Cole via Postfix-users:
> On 2025-02-03 at 13:07:38 UTC-0500 (Mon, 3 Feb 2025 13:07:38 -0500)
> Dan Mahoney via Postfix-users
> is rumored to have said:
>
> > When calling ?postfix reload?, should "postfix/postfix-script: refreshing
> > the Postfix mail
* Josh Good via Postfix-users [31/01/2025 00:37] :
>
> There were community-provided RPM packages of Postfix for Red Hat 6.2
> (Classic), as noted in the original post for this thread, but none of
> them seems to have survived on any publicly accessible repository today.
I had the
On 2025-02-03 at 13:07:38 UTC-0500 (Mon, 3 Feb 2025 13:07:38 -0500)
Dan Mahoney via Postfix-users
is rumored to have said:
> When calling “postfix reload”, should "postfix/postfix-script: refreshing the
> Postfix mail system” be written to stderr?
Yes.
> It’s not an error, and
Dan Mahoney via Postfix-users:
> All,
>
> This is the most minor problem, but I'll bring it up.
>
> We use Lets Encrypt for our certs (using the Dehydrated client),
> and call a 'postfix reload' as part of the hook script if a cert
> has been renewed.
>
>
All,
This is the most minor problem, but I’ll bring it up.
We use Lets Encrypt for our certs (using the Dehydrated client), and call a
“postfix reload” as part of the hook script if a cert has been renewed.
We also wrapper this with ‘cronic’ which works not under the old cron principle
that
Hello,
thanks for the clarification.
Regards
Klaus.
- Nachricht von Wietse Venema via Postfix-users
-
Datum: Mon, 3 Feb 2025 12:02:59 -0500 (EST)
Von: Wietse Venema via Postfix-users
Antwort an: Wietse Venema
Betreff: [pfx] Re: smtpd_end_of_data_restrictions
Klaus Tachtler via Postfix-users:
> Hello,
>
> just so I understand correctly, the recommendation would be to use
> smtpd_end_of_data_restrictions, despite the warning in the Dovecot log?
No. The recommendation is to use the software as intended by its
author, not at
Hello,
just so I understand correctly, the recommendation would be to use
smtpd_end_of_data_restrictions, despite the warning in the Dovecot log?
Thank you
Klaus.
On 2/3/25 17:39, Wietse Venema via Postfix-users wrote:
Klaus Tachtler via Postfix-users:
Hello,
I have a question about
Klaus Tachtler via Postfix-users:
> Hello,
>
> I have a question about smtpd_end_of_data_restrictions. In the
> documentation under the following link
> https://www.postfix.org/SMTPD_ACCESS_README.html#lists there is an
> example which looks like this:
>
> # Enfor
in advance!
Greetings Klaus.
Versions:
=
postfix = 3.9.1-2
dovecot = 2.3.21.1-1
--
---
e-Mail : kl...@tachtler.net
Homepage: https://www.tachtler.net
DokuWiki: https://dokuwiki.tachtler.net
Entrepreneur AJ via Postfix-users:
> But the LMTP connection is timeing out from the second instance (but
> working for the default instance)
>
> I have used tcpdump and can see the connection trying to be established
> but no ack is being received wireshark reading the
emails with instance name postfix-internal keep failing
to pass inbound emails on to dovecot's LMTP (Dovecot is on a different
server (via tcp)) the virtual routing of the messages is working, it's
matching the email addresses to the correct imap accounts and I can
authentication usi
access to the databases. With Nauthilus, the task is
centralized in one place. Nauthilus is essentially an HTTP REST server that can
be accessed by any application. It takes on the role of a guardian.
Nauthilus integrates very well with Dovecot and Postfix.
# Authentication process
Nauthilus uses
On 1/30/25 6:36 PM, Wietse Venema wrote:
So... Do you have any concrete tips for how to adjust SELinux policy
for legitimate Postfix access to 'other' files? The I can drop that
in a Postfix webpage update.
Wietse
I sent you an email off-list. I don't think there'
Thomas Cameron via Postfix-users:
> On 1/30/25 5:06 AM, Viktor Dukhovni via Postfix-users wrote:
> > Those tools are not solutions to the problem, because they're reactive
> > tweaks to discrete instances of a broader mismatch between the policy
> > and requirements.
Josh Good via Postfix-users:
> On 2025 Jan 29, 23:58, Gerald Galster via Postfix-users wrote:
> >
> > > So I am posting here, to ask whether someone has in his archives an RPM
> > > package of Postfix targeted to Red Hat 6.2 (classic edition)?
> >
> > Try
On 2025 Jan 29, 23:58, Gerald Galster via Postfix-users wrote:
>
> > So I am posting here, to ask whether someone has in his archives an RPM
> > package of Postfix targeted to Red Hat 6.2 (classic edition)?
>
> Try to download and mount the ISO(s). Those included RPM packag
On 1/30/25 5:06 AM, Viktor Dukhovni via Postfix-users wrote:
Those tools are not solutions to the problem, because they're reactive
tweaks to discrete instances of a broader mismatch between the policy
and requirements. But the source files from which the policy are
compiled are not typi
Dnia 30.01.2025 o godz. 15:36:26 Peter via Postfix-users pisze:
> At any rate the current Red Hat public download server says that old
> Red Hat Linux images are at
> ftp://archive.download.redhat.com/pub/redhat/linux/, if you can find
> some other way to access it.
That FTP server
On Wed, Jan 29, 2025 at 08:47:47PM -0600, Thomas Cameron via Postfix-users
wrote:
> > This is no worse, imo than any other type of logs, including Postfix
> > logs which can be difficult for a newcomer to fully understand and which
> > has collate to help organise the logs to b
> RHEL 6.2 came with Postfix 2.6.6, not 2.0.6 and you can get a copy from
> CentOS vault:
No, the question was about "Red Hat Linux", not "Red Hat Enterprise Linux".
"Red Hat 6.2" was released long ago in the year 2000.
When dealing with such old systems a co
On 1/29/25 6:50 PM, Peter via Postfix-users wrote:
On 30/01/25 12:00, Wietse Venema via Postfix-users wrote:
If you can get them to address the root cause problem: failing
syscalls without proper logging why) then people could fix these
problem themselves (as the saying goes, "teach a hum
On 30/01/25 15:11, Peter via Postfix-users wrote:
On 30/01/25 11:34, Josh Good via Postfix-users wrote:
Hello all.
Due to reasons which are best left untold, I am setting up a Red Hat 6.2
(classic edition) machine.
This system comes with Sendmail 8.9.3, and it mainly works just fine.
However
On 30/01/25 11:34, Josh Good via Postfix-users wrote:
Hello all.
Due to reasons which are best left untold, I am setting up a Red Hat 6.2
(classic edition) machine.
This system comes with Sendmail 8.9.3, and it mainly works just fine.
However, I was looking for some old Postfix RPM package
On 30/01/25 12:00, Wietse Venema via Postfix-users wrote:
If you can get them to address the root cause problem: failing
syscalls without proper logging why) then people could fix these
problem themselves (as the saying goes, "teach a human to fish").
Except for the very rare case of
Thomas Cameron via Postfix-users:
> Wietse -
>
> I know a little about SELinux. This is me:
> https://www.youtube.com/watch?v=_WOKRaM-HI4 (Security-Enhanced Linux for
> mere mortals on the Red Hat Summit YouTube channel).
>
> If you (or anyone) is running into SELinux pro
> So I am posting here, to ask whether someone has in his archives an RPM
> package of Postfix targeted to Red Hat 6.2 (classic edition)?
Try to download and mount the ISO(s). Those included RPM packages back then.
https://archive.org/details/disc1_202002
The source seems legit, but
Hello all.
Due to reasons which are best left untold, I am setting up a Red Hat 6.2
(classic edition) machine.
This system comes with Sendmail 8.9.3, and it mainly works just fine.
However, I was looking for some old Postfix RPM package suitable for
RH6.2-classic, in order to replace its ugly
adding files to the SELinux
policy), or remediation (think help with building exceptions or policy
modules).
Feel free to reach out to me at work at tho...@redhat.com or on this list.
Thanks,
Thomas
On 1/29/25 10:11 AM, Wietse Venema via Postfix-users wrote:
There are more than a few places in
There are more than a few places in the file system where Postfix
meets the non-Postfix world. This is what I came up with in a few
minutes.
- Pathnames in $forward_path (pathnames for .forward files for UNIX
system accounts). These are accessed while impersonating a recipient.
- Pathnames
On 2025-01-28 at 18:43:50 UTC-0500 (Tue, 28 Jan 2025 17:43:50 -0600)
E R via Postfix-users
is rumored to have said:
On Sat, Dec 21, 2024 at 1:34 AM Michael Tokarev via Postfix-users
wrote:
[...]
The only place for such documentation addition is the Postfix's
readme
file(s), mentionin
On 29/01/25 12:56, E R via Postfix-users wrote:
Yes, I wholeheartedly agree. Even if I disagreed, it would not be one
of the rare Postfix bugs. 8-) As I wrote in another post, I do think
it might be helpful to mention the downside of not using the default
of syslog as I did.
While I don&#
Wietse Venema via Postfix-users wrote in
<4yjls01jvbzj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
|> For the first time ever i today get quite some of
|>
|> Jan 28 22:55:48 ouwa/smtpd[14615]: connect from unknown[unknown]
|> Jan 28 22:55:48 ouwa/
On Sat, Dec 21, 2024 at 4:48 AM Peter via Postfix-users
wrote:
> This is not going to be considered a bug. The configuration shipped
> with the postfix package from RHEL uses syslog to log to the maillog
> file and it's expected that if you change that then you'll be
Ye
On Sat, Dec 21, 2024 at 1:34 AM Michael Tokarev via Postfix-users
wrote:
> The prob with postfix and all these system-specific security mechanisms
> is that you can configure any path for the log file in postfix's main.cf,
> and you have to adjust the security mechanism according
Steffen Nurpmeso via Postfix-users:
> Hello.
>
> For the first time ever i today get quite some of
>
> Jan 28 22:55:48 ouwa/smtpd[14615]: connect from unknown[unknown]
> Jan 28 22:55:48 ouwa/smtpd[14615]: lost connection after CONNECT from
> unknown[unknown]
> Ja
ll, dear collar bear
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
Andr? Gomes via Postfix-users:
> Hi
>
> I`m new on postfix universe.
> I configure a mail server on a dedicated link to send mails to my customers.
> The problem is, i have a old database, (2020, 2021) and i need check these
> emails to avoid any bounce, i dont want my
On 2025-01-28 at 09:25:54 UTC-0500 (Tue, 28 Jan 2025 11:25:54 -0300)
André Gomes via Postfix-users
is rumored to have said:
Hi
I`m new on postfix universe.
I configure a mail server on a dedicated link to send mails to my
customers.
The problem is, i have a old database, (2020, 2021)
You
Hi
I`m new on postfix universe.
I configure a mail server on a dedicated link to send mails to my customers.
The problem is, i have a old database, (2020, 2021) and i need check these
emails to avoid any bounce, i dont want my ip on a blacklist ..
For while i using mailsherpa
https://github.com
On 2025-01-27 at 08:20:19 UTC-0500 (Mon, 27 Jan 2025 14:20:19 +0100)
Marko Cupać via Postfix-users
is rumored to have said:
[...]
... Microsoft's servers are frequently being (temporarily) blocked by
spamcop:
For good cause...
Jan 27 10:47:20 mx1 postfix/smtpd[67827]: NOQUEUE: reject:
On 27.01.25 14:20, Marko Cupać via Postfix-users wrote:
with my current configuration (relevant part):
smtpd_client_restrictions =
check_client_access hash:$config_directory/client_access
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_relay_restrictions
check_sender_access regexp:$config_directory/tagfordirectsend
permit
... Microsoft's servers are frequently being (temporarily) blocked by
spamcop:
Jan 27 10:47:20 mx1 postfix/smtpd[67827]: NOQUEUE: reject: RCPT from
mail-db8eur05on2106.outbound.protection.outlook.com[40.107.20.106]
Dnia 26.01.2025 o godz. 16:28:14 Gerben Wierda via Postfix-users pisze:
>
> So, what happens is: the spammer delivers to the secondary, the secondary
> delivers to the primary, the primary rejects. The secondary then sends an
> undeliverable message to the sender.
Then discard messa
informing senders only some of the time
that they were using the "incorrect" address form?
Wietse
___________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
> On 26 Jan 2025, at 14:33, Wietse Venema via Postfix-users
> wrote:
>
> Gerben Wierda via Postfix-users:
>>
>>> On 23 Jan 2025, at 17:55, Wietse Venema via Postfix-users
>>> wrote:
>>>
>>> Gerben Wierda via Postfix-users:
Gerben Wierda via Postfix-users:
>
> > On 23 Jan 2025, at 17:55, Wietse Venema via Postfix-users
> > wrote:
> >
> > Gerben Wierda via Postfix-users:
> >> I was wondering, suppose I have a user like this:
> >>
> >> f...@bar.com is the
> On 23 Jan 2025, at 17:55, Wietse Venema via Postfix-users
> wrote:
>
> Gerben Wierda via Postfix-users:
>> I was wondering, suppose I have a user like this:
>>
>> f...@bar.com is the account name
>> foo.lastn...@bar.com is the incoming alias and the out
Thanks Victor (& everyone else who chimed in).
I'm going to sit down with management on Monday and see if I can explain
all this to them so as to get a consensus decision on what they'd like
to do.
Cheers
Dulux-Oz
On 26/1/25 12:50, Viktor Dukhovni via Postfix-users wrote:
On Sun, Jan 26, 2025 at 12:11:21AM +1100, duluxoz via Postfix-users wrote:
> ... so no, there's no separate "mail-hub" / "edge-mail-gateway" set-up
> - its all the one box with the haproxy box sitting in-front.
Understood, that makes the consolidated edge/hub/subm
1 - 100 of 7509 matches
Mail list logo
