pt., 10 maj 2024 o 16:13 Wietse Venema via Postfix-users <
postfix-users@postfix.org> napisał(a):
All at once answer, hope it's OK:
IP's:
^
dig mx mxmail.adatum.net +short | cut -d' ' -f2 | xargs dig a +short
10.56.155.14
10.32.32.103
10.32.32.104
10.26.15.31
John Doe via Postfix-users:
> Hi,
>
> I was hoping for real MX record round-robin but it does not work on one of
> my servers.
>
> Somehow, postfix is prioritising one of the MX more than others.
By default, Postfix looks up SMTP servers in DNS, and randomizes
the order of equal-preference
Hi,
I was hoping for real MX record round-robin but it does not work on one of
my servers.
Somehow, postfix is prioritising one of the MX more than others.
Always the same: nlp3.loc-prd.net
All MX servers, are in local network to this client mailserver.
We have relayhost in main.cf:
Yet another "forward", very unfortunate, sorry!
In short: s-dkim-sign generates *correct* Ed25519 signatures,
despite what your DKIM verifier *may* say.
No new release will happen (now, and due to this, at least).
Steffen Nurpmeso wrote in
<20240509012805.7jdxCPXC@steffen%sdaoden.eu>:
|Hello
On Tue, May 07, 2024 at 05:47:59PM +0200, Matus UHLAR - fantomas via
Postfix-users wrote:
> On 07.05.24 17:13, Дилян Палаузов via Postfix-users wrote:
> >I try to understand the difference between alias_database and alias_maps.
>
> >Or, does postalias/newaliases use is alias_database as input,
On 07.05.24 17:13, Дилян Палаузов via Postfix-users wrote:
I try to understand the difference between alias_database and alias_maps.
Or, does postalias/newaliases use is alias_database as input, ignoring
alias_maps, while local ignores alias_databases and uses alias_maps?
Precisely.
Hello,
I try to understand the difference between alias_database and alias_maps.
postconf(5) contains:
alias_database: The alias databases for local(8) delivery that are updated with
"newaliases" or with "sendmail -bi". This is a separate configuration parameter
because not all the tables
That worked :) - Thank you Viktor, much appreciated!
Denis
> On 7 May 2024, at 12:14, Viktor Dukhovni via Postfix-users
> wrote:
>
> On Tue, May 07, 2024 at 10:07:15AM +0200, Denis Krienbühl via Postfix-users
> wrote:
>
>> Ultimately, I ended up with the following rule, but I have a problem
On Tue, May 07, 2024 at 10:07:15AM +0200, Denis Krienbühl via Postfix-users
wrote:
> Ultimately, I ended up with the following rule, but I have a problem with it
> (or any other that I've found):
>
> /^\s*Received:[^\n]+(.*)/ REPLACE Received: from
> [127.0.0.1]
Hi
I'm working on configuring a new mail server instance on Debian Bookworm, with
Postfix 3.7.10-0+deb12u1. To hide internal IP addresses, I'd like to rewrite
the first "Received" header for mails submitted by authenticated users. There
are a number of options I found online, and it seems
On Mon, May 06, 2024 at 11:37:54AM +0200, Дилян Палаузов via Postfix-users
wrote:
> Hello,
>
> postconf(5) contains:
>
> virtual_alias_domains (default: $virtual_alias_maps)
> virtual_alias_maps (default: $virtual_maps)
> virtual_maps (default: empty)
>
> Thus virtual_alias_domains is by
On Mon, May 06, 2024 at 11:37:54AM +0200, Дилян Палаузов via Postfix-users
wrote:
> My reading is that a domain in virtual_alias_domains can be mentioned
> neither in virtual_mailbox_domains nor as mydestination domain.
Correct, note however, that *all* recipients are subject to virtual(5)
Hello,
postconf(5) contains:
virtual_alias_domains (default: $virtual_alias_maps)
virtual_alias_maps (default: $virtual_maps)
virtual_maps (default: empty)
Thus virtual_alias_domains is by default emtpy.
VIRTUAL_README says:
• NEVER list a virtual alias domain name as a mydestination domain!
•
Edgar Fuss via Postfix-users:
> Hello,
>
> I'm looking for prior art on rejecting mails to expired accounts
> including a hint at the new address.
You could use the relocated_maps feature for this. This will reject
at RCPT TO time, with a hard-coded response "5.1.6 User has moved
to ".
You
Hello,
I'm looking for prior art on rejecting mails to expired accounts including a
hint at the new address.
We (Uni Bonn Math Inst) use to forward mails from graduates etc. to a new
address they provide us with when leaving. We would like to only automatically
reply with the new address
Hello.
I am very sorry to disturb again, but please allow me that one in
addition.
(Btw i will not forward *that*, but by the next weekend i will
have released another version of s-postgray which fixes a bug and
gains a new "no-timeout" mode, ie, entries which are so old that
their last usage
Further investigation showed that the issue is in Python 2.7’s `email` module.
Although this is out of support, I’d expect some to be lying around and thought
it worth mentioning to this group. Specifically, `email.Message.__str__()`. It
seems ok in python3
> On 2 May 2024, at 12:53, Tim
Hello,
I’m using openarc from https://github.com/trusteddomainproject/OpenARC
May be dead but does work.
You could try https://github.com/fastmail/authentication_milter
(https://github.com/fastmail/authentication_milter) but it’s way more complex.
cheers
patpro
May 3, 2024 4:17 PM, "Alex via
Hi,
I'm using postfix-3.7.9 on fedora38 and would like to implement ARC to
assist with authenticating emails being forwarded by users to Gmail and
others. The research I've done points to OpenARC as a dead project.
This looks like a great guide to get started, but I'm having trouble
identifying
Norbert Schmidt via Postfix-users:
> Hello,
>
> We've got a single user needing Micro$oft Teams. This users mailaccount
> u...@contenso.com is configured on our server AND within Microsoft365 as
> sending address for the invitations.
> All other mail accounts are local and send via postfix.
>
Hello,
We've got a single user needing Micro$oft Teams. This users mailaccount
u...@contenso.com is configured on our server AND within Microsoft365 as
sending address for the invitations.
All other mail accounts are local and send via postfix.
With blimmen Microsoft365 the invitation mails are
Wietse Venema via Postfix-users wrote in
<4vvgyx1yynzj...@spike.porcupine.org>:
|Wietse Venema via Postfix-users:
|> Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests
|> thts from Postfix. Just need to figure out how to enable/disable
|> this particular command based on the
Wietse Venema via Postfix-users:
> Looks like there is sufficient basis to make SMTPD_QUIT_NC rerquests
> thts from Postfix. Just need to figure out how to enable/disable
> this particular command based on the Postfix and Milter protocol
> versions. There is already some 'set' intersection code
On 2024-05-02 at 07:53:15 UTC-0400 (Thu, 2 May 2024 12:53:15 +0100)
Tim Coote via Postfix-users
is rumored to have said:
What would have helped - and I’ve no idea how feasible this is -
would be some tooling to pull out different versions of the message as
they flow through the queues.
This
On 02.05.24 12:53, Tim Coote via Postfix-users wrote:
I think that I’ve now fixed this in my domain, so I thought I’d just note
the route to finding it, more as a comment on the complexity of working
out what’s going on.
After making a simple robot to send emails with long headers and
I think that I’ve now fixed this in my domain, so I thought I’d just note the
route to finding it, more as a comment on the complexity of working out what’s
going on.
After making a simple robot to send emails with long headers and demonstrating
how they broke in my production environment, I
Hello.
I hope it is acceptable to forward this.
Maybe someone finds it of value.
Thank you for postfix, and thank you all. This list gives very
helpful non-fooling information, and i am grateful it exists.
--- Forwarded from Steffen Nurpmeso ---
...
Tonight i finally uploaded the first
Wietse Venema via Postfix-users wrote in
<4vtb9v00wbzj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
|> But one thing is plain, if lines get folded "artificially" to
|> satisfy line length limits, then this is a whitespace that DKIM
|> will see, and if it was not in the
Steffen Nurpmeso via Postfix-users:
> But one thing is plain, if lines get folded "artificially" to
> satisfy line length limits, then this is a whitespace that DKIM
> will see, and if it was not in the original message, the signature
> will break.
After the DKIM signature is generated, the
Wietse Venema via Postfix-users wrote in
<4vtlbf3vz0zj...@spike.porcupine.org>:
|Postfix does not store line endings internally, because different
|environments have different line ending conventions (for example
|SMTP has while UNIX has ). Postfix strips line endings
|on input, and adds
John Levine wrote in
<20240430015342.8DF9C89B9BE7@ary.local>:
|It appears that Steffen Nurpmeso via Postfix-users \
|said:
|W> |I did not want to insult you!
|>|In mind i had these canon..py snippets
|>|
|>| def strip_trailing_whitespace(content):
|>|return re.sub(b"[\t ]+\r\n",
Postfix does not store line endings internally, because different
environments have different line ending conventions (for example
SMTP has while UNIX has ). Postfix strips line endings
on input, and adds them on output. Postfix was modeled after routers
with different kinds of network
Ml Ml via Postfix-users:
> Hello,
>
> currently we manually use text files for mapping/routing:
>
> # postconf -n |grep -e transport -e alias
> alias_database = hash:/etc/aliases hash:/etc/postfix/aliases
> alias_maps = hash:/etc/aliases hash:/etc/postfix/aliases
> allow_mail_to_commands =
Hello,
currently we manually use text files for mapping/routing:
# postconf -n |grep -e transport -e alias
alias_database = hash:/etc/aliases hash:/etc/postfix/aliases
alias_maps = hash:/etc/aliases hash:/etc/postfix/aliases
allow_mail_to_commands = alias,forward,include
local_transport =
It appears that Steffen Nurpmeso via Postfix-users said:
W> |I did not want to insult you!
> |In mind i had these canon..py snippets
> |
> | def strip_trailing_whitespace(content):
> |return re.sub(b"[\t ]+\r\n", b"\r\n", content)
> |
> |
> | def compress_whitespace(content):
> |return
Steffen Nurpmeso via Postfix-users wrote in
<20240429215451.hPgOZwzc@steffen%sdaoden.eu>:
|Scott Kitterman via Postfix-users wrote in
| <53d75fd8-e109-4712-ba9c-4ea07aa2b...@kitterman.com>:
||On April 29, 2024 9:27:20 PM UTC, Steffen Nurpmeso via Postfix-users \
|| wrote:
||>Tim Coote via
Wietse Venema via Postfix-users wrote in
<4vstkr2gkhzj...@spike.porcupine.org>:
|Steffen Nurpmeso via Postfix-users:
|> Wietse Venema via Postfix-users wrote in
|> <4vsq5f6q3nzj...@spike.porcupine.org>:
|>|Tim Coote via Postfix-users:
|> ..
|>|> SMTP headers are often 'folded' as they
Scott Kitterman via Postfix-users wrote in
<53d75fd8-e109-4712-ba9c-4ea07aa2b...@kitterman.com>:
|On April 29, 2024 9:27:20 PM UTC, Steffen Nurpmeso via Postfix-users \
| wrote:
|>Tim Coote via Postfix-users wrote in
|> :
...
|>|That’s why I formed a hypothesis that (my) Postfix had changed
On April 29, 2024 9:27:20 PM UTC, Steffen Nurpmeso via Postfix-users
wrote:
>Tim Coote via Postfix-users wrote in
> :
> |Thanks very much for the detailed response. My original issue was why \
> |dkim signatures were failing on some emails from email lists when arriving \
> |at my Postfix
Tim Coote via Postfix-users wrote in
:
|Thanks very much for the detailed response. My original issue was why \
|dkim signatures were failing on some emails from email lists when arriving \
|at my Postfix based domain (postfix-3.4.10-1.fc30.x86_64 - I know it \
|needs updating: and that may
Thanks very much for the detailed response. My original issue was why dkim
signatures were failing on some emails from email lists when arriving at my
Postfix based domain (postfix-3.4.10-1.fc30.x86_64 - I know it needs updating:
and that may be the only reasonable answer). I have only seen
Steffen Nurpmeso via Postfix-users:
> Wietse Venema via Postfix-users wrote in
> <4vsq5f6q3nzj...@spike.porcupine.org>:
> |Tim Coote via Postfix-users:
> ..
> |> SMTP headers are often 'folded' as they flow through MTAs. The
> |> standard approach to folding and unfolding is covered in rfcs
Wietse Venema via Postfix-users wrote in
<4vsq5f6q3nzj...@spike.porcupine.org>:
|Tim Coote via Postfix-users:
..
|> SMTP headers are often 'folded' as they flow through MTAs. The
|> standard approach to folding and unfolding is covered in rfcs 5322
...
|3) Lines that exceed 998 bytes (not
Tim Coote via Postfix-users:
> Hullo
>
> I've recently stumbled across this issue and wondered if it's a/
> common, b/ how it can be addressed.
>
> SMTP headers are often 'folded' as they flow through MTAs. The
> standard approach to folding and unfolding is covered in rfcs 5322
> and is relied
Jack Raats:
> Wietse,
>
> I run the script every five minutes for more than 13 hours to the DNS
> server of Cloudflare (2620:fe::fe).
> Four times I had some packet drops (about 25%).
Was that network path in any way similar to the path to your MX
checker? You can check that with mtr (or
I mostly agree - I’ve been using Postfix for a long while now. But something is
folding headers in my domain and failing DKIM that don’t get folded by gmail
and which, if I manually unfold and remove the extra space do get signature
agreement.
Here’s an example:
List-Unsubscribe:
Remember that Postfix has supported DKIM via various milters for
15+ years without issues. So no, practically there is no problem with
DKIM and header folding in Postfix.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an
Hullo
I’ve recently stumbled across this issue and wondered if it’s a/ common, b/ how
it can be addressed.
SMTP headers are often ‘folded’ as they flow through MTAs. The standard
approach to folding and unfolding is covered in rfcs 5322 and is relied on in
6377 (DKIM). Message signing (DKIM)
On Apr 24, 2024, at 09:05, John Levine via Postfix-users
wrote:
I suppose, but sending bare LF in SMTP is definitely wrong, so he needs to
fix that first.
On 28.04.24 19:15, Doug Hardie via Postfix-users wrote:
Well, the header lines are properly terminated by CRLF. However, the text
lines
Wietse,
I run the script every five minutes for more than 13 hours to the DNS
server of Cloudflare (2620:fe::fe).
Four times I had some packet drops (about 25%).
I think that cann't explain why postfix is not reachable on ipv6.
Can postscreen drop an ipv6 connection?
Gr.,
Jack
Op 28-04-2024
On Sun, Apr 28, 2024 at 07:15:38PM -0700, Doug Hardie wrote:
> > I suppose, but sending bare LF in SMTP is definitely wrong, so he needs to
> > fix that first.
>
> Well, the header lines are properly terminated by CRLF. However, the
> text lines are whatever I get from postfix. Generally that
Well, the header lines are properly terminated by CRLF. However, the
text lines are whatever I get from postfix. Generally that is just a
LF. I copied the text and inserted the CRs and sent it to see what
happens. I get the same result: = signs at each fold point.
Those = signs are
-- Doug
> On Apr 24, 2024, at 09:05, John Levine via Postfix-users
> wrote:
>
> It appears that Viktor Dukhovni via Postfix-users
> said:
>> On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users
>> wrote:
>>
I must be interpreting this wrong because it appears
Greetings,
I've been running an ipv4-only postfix system for years, and have dialed
in a set of SMTP access/relay controls that work well for my use case.
I've avoided enabling ipv6 because its lack had yet to cause an issue,
and due to what I'm given to understand has been the wild-west
Jack Raats via Postfix-users:
> In the Netherlands but also in other countries you can use internet.nl
> to test your e-mail and webserver.
> It test your e-mailserver for ipv6 connectivity, SPF, DMARC and DKIM.
>
> My mailserver scores sometimes 100%, but also sometimes lower because it
>
In the Netherlands but also in other countries you can use internet.nl
to test your e-mail and webserver.
It test your e-mailserver for ipv6 connectivity, SPF, DMARC and DKIM.
My mailserver scores sometimes 100%, but also sometimes lower because it
cann't connect postfix on ipv6.
In main.cf
Hi Victor
thanks a lot for the hint to the right direction. Tried first with
sender_dependent_relayhost_maps but this one does not like the
transport name without nexthop. But
sender_dependent_default_transport_maps accepts smtps: without nexthop
:-)
Tested it on our testbox and it behaves like
On Fri, Apr 26, 2024 at 07:21:24AM +0200, Tobi via Postfix-users wrote:
> Or would it be possible to use a sender_dependent_relayhost_maps and
> define just the transport ex smtps: (without nexthop) in there so
> postfix would use that transport (to be defined in master.cf) and the
> normal MX of
Hi
I wonder if it is possible in postfix client to enforce usage of TLS
based on sender. Just like in smtp_tls_policy_maps but based on sender
of the message and not on rcpt or nexthop. The only way I can see so
far is to setup another postfix instance with smtp_tls_security_level =
encrypt and
Wietse Venema via Postfix-users wrote in
<4vqwxx2jpbzj...@spike.porcupine.org>:
|> * For smfi_chgheader, filter order is important. Later
|>filters will see the header changes made by earlier ones.
|
|Yes, that is fundamental to the way that the Milter API works. Each
|Milter
> * For smfi_chgheader, filter order is important. Later
>filters will see the header changes made by earlier ones.
Yes, that is fundamental to the way that the Milter API works. Each
Milter "inspects" the header and body content that exists after
Postfix and previous Milters have
Hello.
I am still writing my DKIM signer (or, actually, for over six
weeks, i got distracted and ran away due to header remove code,
and realization that all RFCs written after Y2K seem to introduce
their own syntax rules instead of simply going for *822 or 2045,
etc etc etc; including DKIM :().
On 15/04/24 10:14, Benny Pedersen via Postfix-users wrote:
Authentication-Results list.sys4.de; dkim=pass
header.d=porcupine.org; arc=none (Message is not ARC signed);
dmarc=pass (Used From Domain Record) header.from=porcupine.org
policy.dmarc=none
On 25.04.24 19:19, Peter via
On 25/04/24 19:42, Benny Pedersen via Postfix-users wrote:
Peter via Postfix-users skrev den 2024-04-25 09:19:
On 15/04/24 10:14, Benny Pedersen via Postfix-users wrote:
Authentication-Results list.sys4.de; dkim=pass
header.d=porcupine.org; arc=none (Message is not ARC signed);
dmarc=pass
Peter via Postfix-users skrev den 2024-04-25 09:22:
You make a confusing, factually incomplete post with claims that are
incorrect and then complain about a lack of clear response on a
different list? If you're going to run down the postfix list for your
own failure at least have the decency
Peter via Postfix-users skrev den 2024-04-25 09:19:
On 15/04/24 10:14, Benny Pedersen via Postfix-users wrote:
Authentication-Results list.sys4.de; dkim=pass
header.d=porcupine.org; arc=none (Message is not ARC signed);
dmarc=pass (Used From Domain Record) header.from=porcupine.org
On 25/04/24 14:34, Benny Pedersen via dovecot wrote:
+1, thanks for dovecot maillist do it right, postfix maillist fails on spf
You make a confusing, factually incomplete post with claims that are
incorrect and then complain about a lack of clear response on a
different list? If you're
On 15/04/24 10:14, Benny Pedersen via Postfix-users wrote:
Authentication-Results list.sys4.de; dkim=pass
header.d=porcupine.org; arc=none (Message is not ARC signed); dmarc=pass
(Used From Domain Record) header.from=porcupine.org policy.dmarc=none
What does this have to to with Postfix,
On Wed, Apr 24, 2024 at 07:23:00PM +0200, Kim Sindalsen via Postfix-users wrote:
> > Regardless, as things stand, the default Fedora 39 nsswitch.conf
> > makes Postfix restrictions much too fragile, and needs to be
> > avoided.
>
> files dns is standard on my installation (Gentoo Linux/OpenRC)
On Wed, Apr 24, 2024, Kim Sindalsen via Postfix-users wrote:
> https://man.archlinux.org/man/nss-resolve.8.en seems to say that the order
> should be:
> mymachines resolve [!UNAVAIL=return] files myhostname
Might be bad advice - we found this problem:
If /etc/nsswitch.conf uses myhostname for
> -Original Message-
> From: Viktor Dukhovni via Postfix-users
> Sent: 24. april 2024 09:19
> To: postfix-users@postfix.org
> Subject: [pfx] Re: IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux
> nsswitch.conf files
>
> On Wed, Apr 24, 2024 at 07:43:35AM +0200, Reto via
It appears that Viktor Dukhovni via Postfix-users
said:
>On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users wrote:
>
>> >I must be interpreting this wrong because it appears postfix is not
>> >accepting that. Here is the complete process. A message arrives at
>> >my MTA
On Wed, Apr 24, 2024 at 07:43:35AM +0200, Reto via Postfix-users wrote:
> On Mon, Apr 22, 2024 at 03:50:34PM GMT, Viktor Dukhovni via Postfix-users
> wrote:
> > and this (specifically, !UNAVAIL=return) turns soft DNS failures into
> > hard errors.
> >
> > The solution, on any production mail
On Mon, Apr 22, 2024 at 03:50:34PM GMT, Viktor Dukhovni via Postfix-users wrote:
> and this (specifically, !UNAVAIL=return) turns soft DNS failures into
> hard errors.
>
> The solution, on any production mail server, is to remove (with
> prejudice)
>
> resolve [!UNAVAIL=return]
This doesn't
On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users wrote:
> >I must be interpreting this wrong because it appears postfix is not
> >accepting that. Here is the complete process. A message arrives at
> >my MTA addressed to a specific address. Postfix delivers that
>
According to Doug Hardie via Postfix-users :
>I must be interpreting this wrong because it appears postfix is not accepting
>that. Here is the complete process. A message arrives at my MTA addressed to
>a specific address. Postfix delivers that
>message to a pipe to my process which reads the
> On Apr 23, 2024, at 12:08, Viktor Dukhovni via Postfix-users
> wrote:
>
> On Tue, Apr 23, 2024 at 11:46:22AM -0700, Doug Hardie via Postfix-users wrote:
>
>>> RFC 3676 addresses this.
>>
>> That was an amazing and helpful response. RFC 2045 showed exactly
>> what caused the problem. When
On Tue, Apr 23, 2024 at 11:46:22AM -0700, Doug Hardie via Postfix-users wrote:
> > RFC 3676 addresses this.
>
> That was an amazing and helpful response. RFC 2045 showed exactly
> what caused the problem. When the message was delivered to a file,
> the CRLFs were replaced by \n. An = followed
> On Apr 22, 2024, at 23:31, Matus UHLAR - fantomas via Postfix-users
> wrote:
>
> On 22.04.24 22:55, Doug Hardie via Postfix-users wrote:
>> This is probably not the right place to be asking this as it is not directly
>> Postfix related, but I don't know a better group to ask. For years I
On 22.04.24 22:55, Doug Hardie via Postfix-users wrote:
This is probably not the right place to be asking this as it is not
directly Postfix related, but I don't know a better group to ask. For
years I have sent text messages and just let the lines run on. Only
inserting a \n for the start
This is probably not the right place to be asking this as it is not directly
Postfix related, but I don't know a better group to ask. For years I have sent
text messages and just let the lines run on. Only inserting a \n for the start
of a
new paragraph. I never exceed the 988 line length
The isi.edu DNS nameservers were apparently being DoSed today, and
reverse and forward lookups (from my MX host) were failing. I was
however surprised to then see:
postfix/smtpd[2530673]: NOQUEUE: reject: RCPT from unknown[128.9.29.254]:
550 5.7.1 Client host rejected: cannot find
Viktor Dukhovni via Postfix-users:
> On Mon, Apr 22, 2024 at 12:21:01AM -0400, 785 243 via Postfix-users wrote:
>
> > Recently i'm seeing a few messages deferred with status=deferred
> > (bounce or trace service failure)
> >
> > instead of status=deferred (host .. said: 450 ...)
> >
> > from
I discovered I had bounce set to discard
I don't recall why, it's been that way for years. Maybe to suppress backscatter.
After i set it back to bounce' i got the expected 550 reject
On Mon, Apr 22, 2024 at 2:09 AM Viktor Dukhovni via Postfix-users
wrote:
>
> On Mon, Apr 22, 2024 at 12:21:01AM
On Mon, Apr 22, 2024 at 12:21:01AM -0400, 785 243 via Postfix-users wrote:
> Recently i'm seeing a few messages deferred with status=deferred
> (bounce or trace service failure)
>
> instead of status=deferred (host .. said: 450 ...)
>
> from the logs:
>
> postfix/smtp[272605]: warning:
Recently i'm seeing a few messages deferred with status=deferred
(bounce or trace service failure)
instead of status=deferred (host .. said: 450 ...)
from the logs:
postfix/smtp[272605]: warning: unexpected protocol
delivery_request_protocol from private/bounce socket (expected:
Wietse Venema via Postfix-users:
> Gino Ferguson via Postfix-users:
> > We have a relay server which has been working fine (postfix
> > 3.3.0-1ubuntu0.4)
> > Now there are ~20K mails in the active queue for a certain recipient
> > and they are just sitting there.
>
> Wietse Venema:
> > What does
Gino Ferguson via Postfix-users:
> We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4)
> Now there are ~20K mails in the active queue for a certain recipient
> and they are just sitting there.
Wietse Venema:
> What does the output look like from:
> grep status=
Nothing. There are no status lines for these certain recipients. The last log
entry is the 'queue active' for each mail.
Sent with Proton Mail secure email.
On Friday, April 19th, 2024 at 2:42 PM, Wietse Venema via Postfix-users
wrote:
> Gino Ferguson via Postfix-users:
>
> > Hi,
> >
Gino Ferguson via Postfix-users:
> Hi,
>
>
> We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4)
>
> Now there are ~20K mails in the active queue for a certain recipient and they
> are just sitting there.
>
What does the output look like from:
grep status=
Hi,
> mailq is reporting what reason?
Nothing:
4VLVl807JrzKmp7* 9499 Fri Apr 19 10:10:28 sender@senderdomain
recipient@recipientdomain
> Try grepping for the queueid of such an email.
I'm over that. The last messages are by the queue
* Gino Ferguson via Postfix-users :
> Hi,
>
>
> We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4)
>
> Now there are ~20K mails in the active queue for a certain recipient and they
> are just sitting there.
mailq is reporting what reason?
> Such an email just
Hi,
We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4)
Now there are ~20K mails in the active queue for a certain recipient and they
are just sitting there.
Such an email just comes in from the client, gets its queue id, etc. and lands
in the active queue. Then it
Wietse Venema via Postfix-users wrote in
<4vkgxb47fdzj...@spike.porcupine.org>:
|Mr. Peng via Postfix-users:
|> I saw this configuration in our master.cf as follows.
|>
|> What's the difference between the option "smtpd_relay_restrictions" and
|> "smtpd_recipient_restrictions"? In my
Thanks a lot for clarifying that @Wietse.
On Thu, Apr 18, 2024 at 10:02 AM Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:
> Mr. Peng via Postfix-users:
> > Hello,
> >
> > I saw this configuration in our master.cf as follows.
> >
> > What's the difference between the option
Mr. Peng via Postfix-users:
> Hello,
>
> I saw this configuration in our master.cf as follows.
>
> What's the difference between the option "smtpd_relay_restrictions" and
> "smtpd_recipient_restrictions"? In my opinion they both mean the sender
> must pass the smtp auth. Thanks.
>
> smtps
Hello,
I saw this configuration in our master.cf as follows.
What's the difference between the option "smtpd_relay_restrictions" and
"smtpd_recipient_restrictions"? In my opinion they both mean the sender
must pass the smtp auth. Thanks.
smtps inet n - y - -
Iker SAENZ via Postfix-users skrev den 2024-04-16 14:14:
postfix-users suscribe
you are already
but incase you like to have one more email address subscribed follow
links below here
List-Id: "For discussions about using Postfix: questions, problem
reports,
or feature requests. Open
postfix-users suscribe
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
On Mon, Apr 15, 2024 at 04:28:33PM +0200, Benny Pedersen via Postfix-users
wrote:
> Dimitris via Postfix-users skrev den 2024-04-15 16:22:
>
> > a totally different approach :
> > you could advise those with gmail accounts to use gmail as an email
> > client and pull emails from your server.
>
801 - 900 of 96910 matches
Mail list logo
