From Newsgroup: alt.os.linux.slackware

I use postfix to send outgoing email. (My MUA is mutt, just in case that
is somehow relevant.)

Every now and then I make the mistake of sending (i.e., trying to send)
email when I'm off-line. This is a mistake, because if postfix doesn't get
the email out on first try, it seems to give up on it entirely.

Running sudo sendmail -v -q doesn't have any effect.
Stopping and restarting the postfix daemon is equally ineffective.

I never had these issues when I used sendmail. (But I switched to postfix
when "everyone" told me it was nicer and newer and shinier than sendmail,
and that sendmail was a horrible security hazard, and ...)

My question: does anyone else (who uses postfix) see this behaviour?

If not, I guess I have to re-examine my configuration.
If so, have you discovered any way to make postfix run the mail in the queue?

Thanks.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim <zsd@jdvb.ca> wrote:

I use postfix to send outgoing email. (My MUA is mutt, just in case that
is somehow relevant.)

Every now and then I make the mistake of sending (i.e., trying to send)
email when I'm off-line.

Email existed during the time before 24/7 connectivity, it (the SMTP
protocol) already handles both senders and receivers not being
network accessible 100% of the time.

This is a mistake, because if postfix doesn't get
the email out on first try, it seems to give up on it entirely.

The server is supposed to retry a small number of times over a period
of time. I don't remember the exact values, but there are probably
postfix configuration words to adjust away from the defaults.

Running sudo sendmail -v -q doesn't have any effect.

That is odd. Note, you didn't say, but, are you running the -q when
you are online? Running that will have no effect if you are offline.

Stopping and restarting the postfix daemon is equally ineffective.

Again, are you doing so when you are online?

My question: does anyone else (who uses postfix) see this behaviour?

If not, I guess I have to re-examine my configuration.

No, but I say that from the perspective of last having postfix handle
email while offline years ago. But even back then, it handled it as
expected. If offline the emails queued. When online, a sendmail -q
would flush the waiting queue out to the internet.

If so, have you discovered any way to make postfix run the mail in

the queue?

sendmail -q is the way -- but you do have to be online, and while
you've implied that you are running it while online, you never
explicitly said so.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware


On Tue, 16 Dec 2025 15:20:45 -0400, Jim wrote:

My question: does anyone else (who uses postfix) see this behaviour?

If not, I guess I have to re-examine my configuration.

postconf maximal_queue_lifetime

what does it say? The default is 5 days

If so, have you discovered any way to make postfix run the mail in

the queue?

mailq - what does it say?

if it reports queued messages, run: sendmail -q

if it shows nothing, show us output of: postconf -n
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim <zsd@jdvb.ca> writes:

I never had these issues when I used sendmail. (But I switched to postfix when "everyone" told me it was nicer and newer and shinier than sendmail,
and that sendmail was a horrible security hazard, and ...)

That was your mistake. Sendmail is GOAT. It's still being actively
developed. The security issues were likely from decades ago or even last century. It's been tried and proven and can route mail no others can
(UUCP, mail11).
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Wed, 17 Dec 2025 11:22:27 -0500, jayjwa wrote:

Jim <zsd@jdvb.ca> writes:

I never had these issues when I used sendmail. (But I switched to

Nobody I know has seen these issues with postfix

century. It's been tried and proven and can route mail no others can
(UUCP, mail11).

oh so sendmail now natively runs sql for its virtual userbase with
hundred thousand domains now does it with a simple config that does not
need rebiulding anythying, and integrates natively with dovecot in such scenarios? runs with NFS now too?

I wont bother looking because I know the answer and it aint good for
sendmail.

uucp ?? PSSSTTTTTTTTTT its no longer 1992

it also takes hours longer to send out a queue of 900K odd emails (even
safter patching sendmail m4's to send concurrently instead of oner after
the other or have they by default fixed that too now? sendmail is however slightly faster than exim, and anything is better than qmail and MS's abominations.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Thu, 18 Dec 2025 14:11:30 +1000, noel wrote:

oh so sendmail ... runs with NFS now too?

What would be the problem with sendmail and NFS? As long as I can
remember, sendmail has worked fine with /var/spool/mail mounted by NFS.
This means that mail sent to user1@host1 can also be read by user1 from
host2 if host1 and host2 mount the same NFS export as their /var/spool/
mail.

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 18.12.2025 06:32 Henrik Carlqvist wrote:

What would be the problem with sendmail and NFS? As long as I can
remember, sendmail has worked fine with /var/spool/mail mounted by
NFS. This means that mail sent to user1@host1 can also be read by
user1 from host2 if host1 and host2 mount the same NFS export as
their /var/spool/ mail.

Does the locking work properly in that case?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Thu, 18 Dec 2025 06:32:09 +0000, Henrik Carlqvist wrote:

On Thu, 18 Dec 2025 14:11:30 +1000, noel wrote:

oh so sendmail ... runs with NFS now too?

What would be the problem with sendmail and NFS? As long as I can
remember, sendmail has worked fine with /var/spool/mail mounted by NFS.
This means that mail sent to user1@host1 can also be read by user1 from
host2 if host1 and host2 mount the same NFS export as their /var/spool/
mail.

regards Henrik

long term problem with NFS and mbox format, many isps's found it didnt
work well, think multiple front ends (we had a couple dozen at peak)
writing to the same user at once, thats why clustered file systems were popular with sendmail because the filesystem would only allow one-write-a- time, that however in itself introduced more complexity and higher
breakage, its why most of us avoid it and went back to ol' faithul NFS,
and maildir moving away from sendmail to postfix gave us all so much
pluses.

I used to be one of sendmails biggest fan in the 90's and early 2000's,
but when something far better and less complex comes along (because we
all know more complexity = more possible links in teh chain to fail, not
to mention all others who have to manage those servers have to be woith
it all as well), after 6 months I regretted not moving our systems over
to postfix sooner, it was 2008 when I made that move.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Tue, 16 Dec 2025 15:20:45 -0400, Jim wrote:

I use postfix to send outgoing email. (My MUA is mutt, just in case
that is somehow relevant.)

Every now and then I make the mistake of sending (i.e., trying to send)
email when I'm off-line. This is a mistake, because if postfix doesn't
get the email out on first try, it seems to give up on it entirely.

[snip]

I use a small Python script called "dupe" for sending email from the
command line.

It connects directly to the SMTP server and sends the message immediately
rCo no local queue or postfix daemon involved.

If you're interested, it's part of the SAM.handy library:

https://rosevearsoftware.com/products/sam/libraries/handy/index.php

Current version is SAM.handy-1.tar.gz.

Just something I wrote for my own use and share in case it's useful to
others.

Joseph


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Thu, 18 Dec 2025 16:32:44 +0100, Marco Moock wrote:

On 18.12.2025 06:32 Henrik Carlqvist wrote:

What would be the problem with sendmail and NFS?

Does the locking work properly in that case?

I have not seen any problems. With later versions of Slackware (maybe
since Slackware 12) I added:

local_lock=flock

to the NFS mount options for /var/spool/mail as well as users home directories. However, I don't remember if I added that because of
sendmail.

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-16 at 19:06 AST, Rich <rich@example.invalid> wrote:

Jim <zsd@jdvb.ca> wrote:

I use postfix to send outgoing email. (My MUA is mutt, just in case that
is somehow relevant.)

Every now and then I make the mistake of sending (i.e., trying to send)
email when I'm off-line.

Email existed during the time before 24/7 connectivity, it (the SMTP protocol) already handles both senders and receivers not being
network accessible 100% of the time.

Yeah. I've been using email since 1979. I say "mistake" because of what
is happening on my system these days with postfix.

This is a mistake, because if postfix doesn't get
the email out on first try, it seems to give up on it entirely.

The server is supposed to retry a small number of times over a period
of time. I don't remember the exact values, but there are probably
postfix configuration words to adjust away from the defaults.

This is how I understand it as well. And yet...

Running sudo sendmail -v -q doesn't have any effect.

That is odd. Note, you didn't say, but, are you running the -q when
you are online? Running that will have no effect if you are offline.

Yes, thanks. I try it when I know I am on-line and my outgoing SMTP server
is reachable.

Stopping and restarting the postfix daemon is equally ineffective.

Again, are you doing so when you are online?

Yes.

My question: does anyone else (who uses postfix) see this behaviour?

If not, I guess I have to re-examine my configuration.

No, but I say that from the perspective of last having postfix handle
email while offline years ago. But even back then, it handled it as expected. If offline the emails queued. When online, a sendmail -q
would flush the waiting queue out to the internet.

If so, have you discovered any way to make postfix run the mail in

the queue?

sendmail -q is the way -- but you do have to be online, and while
you've implied that you are running it while online, you never
explicitly said so.

Mea culpa!

Thanks for the thoughts anyway.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-17 at 04:33 AST, noel <deletethis@invalid.lan> wrote:

On Tue, 16 Dec 2025 15:20:45 -0400, Jim wrote:

My question: does anyone else (who uses postfix) see this behaviour?

If not, I guess I have to re-examine my configuration.

postconf maximal_queue_lifetime

what does it say? The default is 5 days

As is mine:
maximal_queue_lifetime = 5d

If so, have you discovered any way to make postfix run the mail in

the queue?

mailq - what does it say?

It tells me there are mail message(s) waiting to be sent.

if it reports queued messages, run: sendmail -q

if it shows nothing, show us output of: postconf -n

And unfortunately, sendmail -q (I use -v as well) while the network is up
has no effect, the mail is not sent, and mailq continues to report that
there is mail waiting to be sent.

Thanks for the reply.
Jim

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-17 at 12:22 AST, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:

Jim <zsd@jdvb.ca> writes:

I never had these issues when I used sendmail. (But I switched to postfix >> when "everyone" told me it was nicer and newer and shinier than sendmail,
and that sendmail was a horrible security hazard, and ...)

That was your mistake. Sendmail is GOAT.

Oh yeah, and I've heard that if you run sendmail your dog will bite you and
run away with the postman, your hair will fall out, your investments will
all tank, ... :-)

It's still being actively developed. The security issues were likely from decades ago or even last century. It's been tried and proven and can
route mail no others can (UUCP, mail11).

And yet Pat V dispatched sendmail to the wasteland of extra/. :-)

Not that I can't install it from there. But (as I recall) I was running
into some issues with my outgoing mail servers no longer accepting mail
that didn't have a "From:" address in their domain, and (almost) all of
them wanting authentication, and needing to configure things so that
sendmail or postfix or ... would attempt the correct form of authentication with the right credentials depending on the email's "From:" address.
IIRC someone was able to set me on the straight and narrow for postfix, and
I wasn't having luck with sendmail, so over to the (supposedly) easier
postfix I went.

Cheers.
Jim

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-19 at 03:54 AST, Joseph Rosevear <Mail@JoesLife.org> wrote:

On Tue, 16 Dec 2025 15:20:45 -0400, Jim wrote:

I use postfix to send outgoing email. (My MUA is mutt, just in case
that is somehow relevant.)

Every now and then I make the mistake of sending (i.e., trying to send)
email when I'm off-line. This is a mistake, because if postfix doesn't
get the email out on first try, it seems to give up on it entirely.

[snip]

I use a small Python script called "dupe" for sending email from the
command line.

It connects directly to the SMTP server and sends the message immediately rCo no local queue or postfix daemon involved.

If you're interested, it's part of the SAM.handy library:

https://rosevearsoftware.com/products/sam/libraries/handy/index.php

Current version is SAM.handy-1.tar.gz.

Just something I wrote for my own use and share in case it's useful to others.

Joseph

Thanks Joe, I can see the benefit of having a script like that.

Unfortunately, it doesn't (directly, anyway) solve the problem of postfix *sometimes* not sending email which I generate using my "favourite" mail
user agent.

Nonetheless, it does do a nice end-run around recalcitrant mail transfer agents, at the cost of a certain amount of preparing the correct arguments.

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Mon, 22 Dec 2025 17:34:40 -0400, Jim Diamond wrote:

mailq - what does it say?

It tells me there are mail message(s) waiting to be sent.

And unfortunately, sendmail -q (I use -v as well) while the network is
up has no effect, the mail is not sent, and mailq continues to report
that there is mail waiting to be sent.

OK first, what is the reason? tail -n20 maillog (if you run it
through amavis or mailscanner use -n60)

(you can sanitise your server name, and any email addresses - so long as
you are sure there is no typo in the emails - I suggest replace left hand
side with xxxxxxxxxxxxx and leave the host/domain part intact)

This might allow identifying the reason, else the next command will haver
to be run again and again and again, when you should never have to.

THEN

postqueue -f


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim, I would expect that you should be able to find some insight as to
why Postfix is failing to send queued messages in your maillog. As it
is, I suspect that folks could only otherwise guess at what the cause is without seeing some log extracts anyway.

On 2025-12-22, Jim Diamond wrote:

Oh yeah, and I've heard that if you run sendmail your dog will
bite you and run away with the postman, your hair will fall out,
your investments will all tank, ... :-)

Right. These things *might* have happened to whomever told you they
would, but the truth is that they happened *only* because those people
had specifically configured Sendmail to cause them. ;-)

Seriously, Sendmail has been around as long as it has because it can
dispatch mail messages in ways other mail software won't. Admittedly,
not everyone needs to dispatch mail in all of those ways, so other
mail transport software has gained in popularity. YMMV, but in my
opinion, that isn't any reason to move away from something that is
known to work and work well.

And yet Pat V dispatched sendmail to the wasteland of extra/. :-)

Yeah ... probably because a) he sees value in the reportedly simpler configuration for Postfix, or b) he felt a demand from folks who
use Slackware regularly, test the "current" branch, and report back
their experiences. (or of course, any number of other possible
reasons that might be closer to the truth ...)

The greatest thing about Slackware, in my opinion, though, is that
you're left in charge of your own system. Both packages are provided
because some folks will prefer one while others will prefer the other.
One had to be selected as the default. Most other Linux distributions
seem to be defaulting to Postfix, so it might have seemed like a
natural choice.

My own systems still use Sendmail, and likely will continue to until
such time as that no longer feels like the right choice. I don't
see a need to switch just because others have switched. That said,
I've been finding lately that some of my similar attitudes about
software have been leaving me feeling a bit like a dinosaur ...

... But (as I recall) I was running into some issues with my
outgoing mail servers no longer accepting mail that didn't have a
"From:" address in their domain, and (almost) all of them wanting authentication, and needing to configure things so that sendmail or
postfix or ... would attempt the correct form of authentication with
the right credentials depending on the email's "From:" address. ...

Ah ... is it possible that you're running into similar issues here with Postfix, then? Again, your logs should give some insight. This is a
question of mail tranport software acting as a "client" when relaying
mail through the service provider's mail server, while simultaneously
acting as a "server" when accepting messages from your mail user agent.

It can be a little bit confusing, conceptually, until you fully
understand the path(s) that your messages take to get to their
destinations.

I hope that I've helped you look sufficiently further into the problem
that the solution might present itself. Happy holidays.
--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca ----------------------------------------------------------------------
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-22 at 18:12 AST, noel <deletethis@invalid.lan> wrote:

On Mon, 22 Dec 2025 17:34:40 -0400, Jim Diamond wrote:

mailq - what does it say?

It tells me there are mail message(s) waiting to be sent.


And unfortunately, sendmail -q (I use -v as well) while the network is
up has no effect, the mail is not sent, and mailq continues to report
that there is mail waiting to be sent.

OK first, what is the reason? tail -n20 maillog (if you run it
through amavis or mailscanner use -n60)

I had to go back in time more than 20 lines. :-)
See below.

(you can sanitise your server name, and any email addresses - so long as
you are sure there is no typo in the emails - I suggest replace left hand side with xxxxxxxxxxxxx and leave the host/domain part intact)

Here is the message in maillog when it tried to send an email while the
network was down:

------------------
Dec 16 15:05:58 x360 postfix/pickup[1480]: AA6B21E0B4C: uid=1000 from=<MY_ADDR> Dec 16 15:05:58 x360 postfix/cleanup[2477]: AA6B21E0B4C: message-id=<aUGtlsa5qHdUlcC7@x360.localdomain>
Dec 16 15:05:58 x360 postfix/qmgr[3285]: AA6B21E0B4C: from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4
Dec 16 15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2 IPv4 addresses
Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C: from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------

However, I am able to do this until the cows come home, and even though new emails will get out, the one in queue seems to get the status=deferred
response ad infinitum. (OK, I didn't let it go until infinity, so that
last part is bold hyperbole. But I previous cases I tried many times, to
no avail.)

Eventually I give up and resend the message from my MUA and manually remove
the two email files from /var/spool.

This might allow identifying the reason, else the next command will haver
to be run again and again and again, when you should never have to.

THEN

postqueue -f

I type
sendmail -v -q
out of habit, but the sendmail (postfix version) man page leads me to
believe that "sendmail -q" == "postqueue -f".

I don't know if the above bits from maillog tell you anything, aside from seeing that it was continuing to insist that it couldn't look up my SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Hi Sylvain,

On 2025-12-24 at 18:34 AST, Sylvain Robitaille <syl@therockgarden.ca> wrote:

Jim, I would expect that you should be able to find some insight as to
why Postfix is failing to send queued messages in your maillog. As it
is, I suspect that folks could only otherwise guess at what the cause is without seeing some log extracts anyway.

Yes, I absolutely should have sent those in my first message. But
sometimes one gets lucky and 12 people will instantly pipe up and say "I
know what that is!".

Not this time.

As you might have seen when you read this, I sent them in my reply to Noel.

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim Diamond <zsd@jdvb.ca> wrote:

Here is the message in maillog when it tried to send an email while the network was down:

------------------
Dec 16 15:05:58 x360 postfix/pickup[1480]: AA6B21E0B4C: uid=1000 from=<MY_ADDR>
Dec 16 15:05:58 x360 postfix/cleanup[2477]: AA6B21E0B4C: message-id=<aUGtlsa5qHdUlcC7@x360.localdomain>
Dec 16 15:05:58 x360 postfix/qmgr[3285]: AA6B21E0B4C: from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=0.05,
delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=MY_SMTP_SERVER type=A: Host
not found, try again)
------------------

Grep your postfix config files for the string "MY_SMTP_SERVER". It
looks like you may have enabled an option somewhere, but did not change
the text you were supposed to change to be the domain name of the
actual server.

That is, unless your servers DNS name is actually "MY_SMTP_SEVER" (not likely).


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-25 at 00:25 AST, Rich <rich@example.invalid> wrote:

Jim Diamond <zsd@jdvb.ca> wrote:

Here is the message in maillog when it tried to send an email while the
network was down:

------------------
Dec 16 15:05:58 x360 postfix/pickup[1480]: AA6B21E0B4C: uid=1000 from=<MY_ADDR>
Dec 16 15:05:58 x360 postfix/cleanup[2477]: AA6B21E0B4C: message-id=<aUGtlsa5qHdUlcC7@x360.localdomain>
Dec 16 15:05:58 x360 postfix/qmgr[3285]: AA6B21E0B4C: from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C:
to=<ntg-context@ntg.nl>, relay=none, delay=0.05,
delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=MY_SMTP_SERVER type=A: Host
not found, try again)
------------------

Grep your postfix config files for the string "MY_SMTP_SERVER". It
looks like you may have enabled an option somewhere, but did not change
the text you were supposed to change to be the domain name of the
actual server.

That is, unless your servers DNS name is actually "MY_SMTP_SEVER" (not likely).

As per Noel's suggestion, I "sanitized" some of the addresses in my posting.

Also as I mentioned in my first message, it works fine when I am on-line
when the message is going out. So the setup is (basically, at least)
correct.

Cheers.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-25, Jim Diamond wrote:

Here is the message in maillog when it tried to send an email while the network was down:

------------------
...
Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------

Ok, that's not surprising ...

Once the network was back, I tried running the queue:

------------------
...
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------

But this is ...

Here's a thought ... It won't help solve the problem but it might
help identify the cause ...

Perhaps just before and just after running "sendmail -v -q" try running
"getent hosts MY_SMTP_SERVER" (with the correct hostname, of course)
and confirm that the system is generally able to resolve the hostname?

Based on the timestamps from your log extracts above, I'm guessing
(and yes, only guessing) that the attempt to flush the mail queue
is happening before the resolver is able to fulfill its role.
My suggestion here might help confirm or disprove that. I hope that
it helps.
--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca ----------------------------------------------------------------------
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Sylvain Robitaille writes:

Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-

context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)

------------------

But this is ...

Here's a thought ... It won't help solve the problem but it might
help identify the cause ...

Perhaps just before and just after running "sendmail -v -q" try running "getent hosts MY_SMTP_SERVER" (with the correct hostname, of course)
and confirm that the system is generally able to resolve the hostname?

Postfix is unlikely to be using glibc to resolve hostnames, but rather it's making direct DNS queries, either by doing it itself or using a resolver library. The "type=A" part of the syslog message is a honking clue.

In which case, it would be more accurate to reproduce what postfix is doing by running dig:

dig MY_SMTP_SERVER a


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Wed, 24 Dec 2025 20:12:49 -0400, Jim Diamond wrote:

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4 Dec 16
15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2
IPv4 addresses Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C: from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0,
dsn=4.4.3, status=deferred (Host or domain name not found. Name service
error for name=MY_SMTP_SERVER type=A: Host not found, try again) ------------------

I don't know if the above bits from maillog tell you anything, aside
from seeing that it was continuing to insist that it couldn't look up my
SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim

Jim,

This tells me everything, the DNS failures carry through!

run exactly this: postsuper -r ALL

This *should* do fresh DNS requests and send every message in your queue
if you are online

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-25 at 19:37 AST, Sylvain Robitaille <syl@therockgarden.ca> wrote:

On 2025-12-25, Jim Diamond wrote:

Here is the message in maillog when it tried to send an email while the
network was down:

------------------
...
Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------

Ok, that's not surprising ...

Once the network was back, I tried running the queue:

------------------
...
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------

But this is ...

Yeah, surprises me too.

Here's a thought ... It won't help solve the problem but it might
help identify the cause ...

Perhaps just before and just after running "sendmail -v -q" try running "getent hosts MY_SMTP_SERVER" (with the correct hostname, of course)
and confirm that the system is generally able to resolve the hostname?

Based on the timestamps from your log extracts above, I'm guessing
(and yes, only guessing) that the attempt to flush the mail queue
is happening before the resolver is able to fulfill its role.
My suggestion here might help confirm or disprove that. I hope that
it helps.

Thanks for the idea. I will give it a try the next time I do this to
myself. (I have long since cleaned /var/spool and resent the message.)

In the above case, unless my memory completely fails me, the network was up
and running properly (although that does not preclude the possibility that there was some issue looking up my particular mail server). Having said
that, in past cases I tried to encourage postfix by sending other emails
while the stuck one was in the queue, and those emails went happily on
their way. Which makes me think that postfix is doing something weird with mail messages that have already failed, as opposed to having issues finding
the server.

Having said that, not having perused the postfix code, I will admit to
having little idea of what is going on inside.

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-25 at 21:34 AST, Sam <sam@email-scan.com> wrote:

Sylvain Robitaille writes:

Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<ntg-

context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0, dsn=4.4.3,
status=deferred (Host or domain name not found. Name service error for
name=MY_SMTP_SERVER type=A: Host not found, try again)

------------------

But this is ...

Here's a thought ... It won't help solve the problem but it might
help identify the cause ...

Perhaps just before and just after running "sendmail -v -q" try running
"getent hosts MY_SMTP_SERVER" (with the correct hostname, of course)
and confirm that the system is generally able to resolve the hostname?

Postfix is unlikely to be using glibc to resolve hostnames, but rather it's making direct DNS queries, either by doing it itself or using a resolver library. The "type=A" part of the syslog message is a honking clue.

In which case, it would be more accurate to reproduce what postfix is doing by running dig:

dig MY_SMTP_SERVER a

Sam, thanks for the thoughts. As I mentioned in another reply (well after
your posting) when the same problem happened another time, I successfully
sent out many emails while the stuck one remained in the queue, which tells
me that postfix was able to find my mail server for new email.

The next time this happens I'll take a closer look at ensuring my mail
server is reachable.

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-25 at 22:13 AST, noel <deletethis@invalid.lan> wrote:

On Wed, 24 Dec 2025 20:12:49 -0400, Jim Diamond wrote:

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4 Dec 16
15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2
IPv4 addresses Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C:
from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C:
to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0,
dsn=4.4.3, status=deferred (Host or domain name not found. Name service
error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------



I don't know if the above bits from maillog tell you anything, aside
from seeing that it was continuing to insist that it couldn't look up my
SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim

Jim,

This tells me everything, the DNS failures carry through!

run exactly this: postsuper -r ALL

This *should* do fresh DNS requests and send every message in your queue
if you are online

Noel,

thanks for the suggestion, I was unfamiliar with that command. I will give
it a try next time I have this issue.

When you say "the DNS failures carry through!", are saying that postfix,
rather than trying a new DNS lookup for an email in the queue, doesn't
bother trying again and doubles down on its "DNS failure" thought?

If so, does that sound like a bug to you? It sounds like a bug to me, but maybe there is some other issue in play which causes that behaviour to be
what is desired.

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim <zsd@jdvb.ca> wrote:

On 2025-12-25 at 22:13 AST, noel <deletethis@invalid.lan> wrote:

On Wed, 24 Dec 2025 20:12:49 -0400, Jim Diamond wrote:

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4 Dec 16
15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2
IPv4 addresses Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C:
from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C:
to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0,
dsn=4.4.3, status=deferred (Host or domain name not found. Name service
error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------



I don't know if the above bits from maillog tell you anything, aside
from seeing that it was continuing to insist that it couldn't look up my >>> SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim

Jim,

This tells me everything, the DNS failures carry through!

run exactly this: postsuper -r ALL

This *should* do fresh DNS requests and send every message in your queue
if you are online

Noel,

thanks for the suggestion, I was unfamiliar with that command. I will give it a try next time I have this issue.

When you say "the DNS failures carry through!", are saying that postfix, rather than trying a new DNS lookup for an email in the queue, doesn't
bother trying again and doubles down on its "DNS failure" thought?

If so, does that sound like a bug to you? It sounds like a bug to me, but maybe there is some other issue in play which causes that behaviour to be what is desired.

What is the setting for "address_verify_negative_cache" in your postfix configuration?

Also, you may want to take a look at the "dialup configuration"
settings in the Postfix docs:

https://www.postfix.org/STANDARD_CONFIGURATION_README.html#dialup

While I don't recall you indicating 'why' you have intermittent network connectivity, a system using "dialup" is also a system with
'intermittent network connectivity'. So some settings for dialup may
be appropriate for your usecase as well.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

--=_ripper.email-scan.com-27777-1766926679-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Jim Diamond writes:

Sam, thanks for the thoughts. As I mentioned in another reply (well after your posting) when the same problem happened another time, I successfully sent out many emails while the stuck one remained in the queue, which tells me that postfix was able to find my mail server for new email.

That sounds like Postfix is waiting for some time to elapse before trying to resent the stuck email.

I am not familiar with Postfix's internal logic, but this is the most plausible explanation: if an attempt to deliver a message fails, try again only after a prescribed period of time. Even though other messages, to the same destination, are now getting delivered normally, the delayed message won't be tried again until it finishes its time in the penalty box.

Postfix might require some specific command to retry one or more held messages immediately.


--=_ripper.email-scan.com-27777-1766926679-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaVEpVwAKCRCKYPgoojZS 4pdiAP9diaLFWIBBL1HWg2GM/2wDEUWv1ko046iytTDwbWVlLwEAjq0XreB91Qjw wZFztuPivvqcFx9MQuW0FCKM4N7YPQs=
=W4JC
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-27777-1766926679-0001--
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-28 at 01:19 AST, Rich <rich@example.invalid> wrote:

Jim <zsd@jdvb.ca> wrote:

On 2025-12-25 at 22:13 AST, noel <deletethis@invalid.lan> wrote:

On Wed, 24 Dec 2025 20:12:49 -0400, Jim Diamond wrote:

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4 Dec 16
15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2
IPv4 addresses Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C:
from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C:
to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0,
dsn=4.4.3, status=deferred (Host or domain name not found. Name service >>>> error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------



I don't know if the above bits from maillog tell you anything, aside
from seeing that it was continuing to insist that it couldn't look up my >>>> SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim

Jim,

This tells me everything, the DNS failures carry through!

run exactly this: postsuper -r ALL

This *should* do fresh DNS requests and send every message in your queue >>> if you are online

Noel,

thanks for the suggestion, I was unfamiliar with that command. I will give >> it a try next time I have this issue.

When you say "the DNS failures carry through!", are saying that postfix,
rather than trying a new DNS lookup for an email in the queue, doesn't
bother trying again and doubles down on its "DNS failure" thought?

If so, does that sound like a bug to you? It sounds like a bug to me, but >> maybe there is some other issue in play which causes that behaviour to be
what is desired.

What is the setting for "address_verify_negative_cache" in your postfix configuration?

address_verify_negative_cache = yes

Also, you may want to take a look at the "dialup configuration"
settings in the Postfix docs:

https://www.postfix.org/STANDARD_CONFIGURATION_README.html#dialup

While I don't recall you indicating 'why' you have intermittent network connectivity,

Good question. It is just the rare weird situation, like shutting the lid
on my laptop injudiciously quickly after sending an email, and I am able to
do that before (apparently) the DNS lookup happens. On wakeup, postfix immediately gets back on the job, whereas the wifi takes a couple of
seconds to connect, so the DNS lookup doesn't happen.

a system using "dialup" is also a system with 'intermittent network connectivity'. So some settings for dialup may be appropriate for your usecase as well.

Thanks for the pointer. I'll take a look at that tomorrow. (I still think postfix should just get on with the job of sending the mail in the queue,
but if I need to apply work-arounds, I guess that is what I will need to do.)

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim Diamond <zsd@jdvb.ca> wrote:

On 2025-12-28 at 01:19 AST, Rich <rich@example.invalid> wrote:

Jim <zsd@jdvb.ca> wrote:

On 2025-12-25 at 22:13 AST, noel <deletethis@invalid.lan> wrote:

On Wed, 24 Dec 2025 20:12:49 -0400, Jim Diamond wrote:

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4 Dec 16 >>>>> 15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2 >>>>> IPv4 addresses Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C: >>>>> from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C:
to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0,
dsn=4.4.3, status=deferred (Host or domain name not found. Name service >>>>> error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------



I don't know if the above bits from maillog tell you anything, aside >>>>> from seeing that it was continuing to insist that it couldn't look up my >>>>> SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim

Jim,

This tells me everything, the DNS failures carry through!

run exactly this: postsuper -r ALL

This *should* do fresh DNS requests and send every message in your queue >>>> if you are online

Noel,

thanks for the suggestion, I was unfamiliar with that command. I will give >>> it a try next time I have this issue.

When you say "the DNS failures carry through!", are saying that postfix, >>> rather than trying a new DNS lookup for an email in the queue, doesn't
bother trying again and doubles down on its "DNS failure" thought?

If so, does that sound like a bug to you? It sounds like a bug to me, but >>> maybe there is some other issue in play which causes that behaviour to be >>> what is desired.

What is the setting for "address_verify_negative_cache" in your postfix
configuration?

address_verify_negative_cache = yes

Then try a test with it set to "no" (reload/restart postfix after the
change) and see if that makes a difference. The docs imply this option
caches for some time the fact that an address lookup failed. If so,
this might be why some emails are getting 'stuck'.

a system using "dialup" is also a system with 'intermittent network
connectivity'. So some settings for dialup may be appropriate for your
usecase as well.

Thanks for the pointer. I'll take a look at that tomorrow. (I still think postfix should just get on with the job of sending the mail in the queue,
but if I need to apply work-arounds, I guess that is what I will need to do.)

Keep in mind that the 'correct' configuration settings for a mail
server that should have 24/7 connectivity will differ from one that is expected to only have intermittent connectivity. Slackware's defaults
(likely very close or identical to Postfix's defaults) very likely
presume 24/7 connectivity (as that is a majority situation today in
2025) and one or more of those settings is likely what is causing the 'stuckness' factor.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-28 at 08:57 AST, Sam <sam@email-scan.com> wrote:

This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

Jim Diamond writes:

Sam, thanks for the thoughts. As I mentioned in another reply (well after >> your posting) when the same problem happened another time, I successfully
sent out many emails while the stuck one remained in the queue, which tells >> me that postfix was able to find my mail server for new email.

That sounds like Postfix is waiting for some time to elapse before trying to
resent the stuck email.

I am not familiar with Postfix's internal logic, but this is the most plausible explanation: if an attempt to deliver a message fails, try again only after a prescribed period of time. Even though other messages, to the same destination, are now getting delivered normally, the delayed message won't be tried again until it finishes its time in the penalty box.

Postfix might require some specific command to retry one or more held messages immediately.

AIUI (*cough*), that is what "sendmail -q" should do, and (as I think I mentioned earlier) that has no useful effect whatsoever.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-29 at 14:06 AST, Rich <rich@example.invalid> wrote:

Jim Diamond <zsd@jdvb.ca> wrote:

On 2025-12-28 at 01:19 AST, Rich <rich@example.invalid> wrote:

Jim <zsd@jdvb.ca> wrote:

On 2025-12-25 at 22:13 AST, noel <deletethis@invalid.lan> wrote:

On Wed, 24 Dec 2025 20:12:49 -0400, Jim Diamond wrote:

Once the network was back, I tried running the queue:

------------------
Dec 16 15:06:17 x360 postfix/postqueue[2613]: name_mask: ipv4 Dec 16 >>>>>> 15:06:17 x360 postfix/postqueue[2613]: inet_addr_local: configured 2 >>>>>> IPv4 addresses Dec 16 15:06:17 x360 postfix/qmgr[3285]: AA6B21E0B4C: >>>>>> from=<MY_ADDR>, size=2073, nrcpt=1 (queue active)
Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C:
to=<ntg-context@ntg.nl>, relay=none, delay=19, delays=19/0/0/0,
dsn=4.4.3, status=deferred (Host or domain name not found. Name service >>>>>> error for name=MY_SMTP_SERVER type=A: Host not found, try again)
------------------



I don't know if the above bits from maillog tell you anything, aside >>>>>> from seeing that it was continuing to insist that it couldn't look up my >>>>>> SMTP server. If you have some extra insight there, I'm all ears.

Cheers.
Jim

Jim,

This tells me everything, the DNS failures carry through!

run exactly this: postsuper -r ALL

This *should* do fresh DNS requests and send every message in your queue >>>>> if you are online

Noel,

thanks for the suggestion, I was unfamiliar with that command. I will give
it a try next time I have this issue.

When you say "the DNS failures carry through!", are saying that postfix, >>>> rather than trying a new DNS lookup for an email in the queue, doesn't >>>> bother trying again and doubles down on its "DNS failure" thought?

If so, does that sound like a bug to you? It sounds like a bug to me, but >>>> maybe there is some other issue in play which causes that behaviour to be >>>> what is desired.

What is the setting for "address_verify_negative_cache" in your postfix >>> configuration?

address_verify_negative_cache = yes

Then try a test with it set to "no" (reload/restart postfix after the change) and see if that makes a difference. The docs imply this option caches for some time the fact that an address lookup failed. If so,
this might be why some emails are getting 'stuck'.

The next time postfix does that to me, I'll give it a whirl, thanks.

a system using "dialup" is also a system with 'intermittent network
connectivity'. So some settings for dialup may be appropriate for your
usecase as well.

Thanks for the pointer. I'll take a look at that tomorrow. (I still think >> postfix should just get on with the job of sending the mail in the queue,
but if I need to apply work-arounds, I guess that is what I will need to do.)

Keep in mind that the 'correct' configuration settings for a mail
server that should have 24/7 connectivity will differ from one that is expected to only have intermittent connectivity. Slackware's defaults (likely very close or identical to Postfix's defaults) very likely
presume 24/7 connectivity (as that is a majority situation today in
2025) and one or more of those settings is likely what is causing the 'stuckness' factor.

I read the docs you referred me to, and nothing there jumped out at me (vis-a-vis the issue I'm having).

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Mon, 29 Dec 2025 18:06:19 +0000, Rich wrote:

address_verify_negative_cache = yes

Then try a test with it set to "no" (reload/restart postfix after the
change) and see if that makes a difference. The docs imply this option

You can change the default cache time, but yes read the docs, because I
can't recall what that setting is, I think the default is (wrongfully)
set to a few days, neg cache should expire after a few hours IMHO, but
good luck convincing wietse that :)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

--=_ripper.email-scan.com-1699036-1767187072-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Jim Diamond writes:

Postfix might require some specific command to retry one or more held messages immediately.

AIUI (*cough*), that is what "sendmail -q" should do, and (as I think I mentioned earlier) that has no useful effect whatsoever.

Then the next step up the ladder is DNS resolution. Postfix is not going to cache DNS queries by itself. If this was anything other than Slackware then my next suggestion would be to uninstall systemd-resolved and fix /etc/ resolv.conf, which never fails to fix these kinds of issues. But, that's not the case here.

Does anything useful get logged to syslog when "sendmail -q" is run, and
no delivery attempts are made. Does Postfix normally log something for every delivery attempt. Is there a config setting in Postfix that increases the logging level. You want to get to the point where every mail delivery
attempt gets logged, and then see what happens when "sendmail -q" does not
do anything.


--=_ripper.email-scan.com-1699036-1767187072-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaVUigAAKCRCKYPgoojZS 4tTmAP9XjVkAAIOzb0U9z/bDMXbiL5iwtQE1K0pPh1Ut8skVBwD/bv0hwmC0PnWc aFmTm0COQOUM+wLQDZIZwsNmVmJoPAE=
=Mt+R
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-1699036-1767187072-0001--
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Sam <sam@email-scan.com> writes:

Then the next step up the ladder is DNS resolution. Postfix is not
going to cache DNS queries by itself. If this was anything other than Slackware then my next suggestion would be to uninstall
systemd-resolved and fix /etc/resolv.conf, which never fails to fix
these kinds of issues. But, that's not the case here.

Is nscd running? Is /etc/resolvconf.conf in effect (if on Current)? resolvconf.conf will mess with resolv.conf. Config files to write config
files for simple things. Yes, we are at that level of insanity.

getent hosts (whatever host you're looking at)
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-31 at 14:03 AST, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:

Sam <sam@email-scan.com> writes:

Then the next step up the ladder is DNS resolution. Postfix is not
going to cache DNS queries by itself. If this was anything other than
Slackware then my next suggestion would be to uninstall
systemd-resolved and fix /etc/resolv.conf, which never fails to fix
these kinds of issues. But, that's not the case here.

Is nscd running?

No.

Is /etc/resolvconf.conf in effect (if on Current)?

Yes in effect, but I am on 15.0.

resolvconf.conf will mess with resolv.conf. Config files to write config files for simple things. Yes, we are at that level of insanity.

Don't mention it in public, because someone will want to one-up that by
writing config files for config files for config files.

getent hosts (whatever host you're looking at)

That gives me the expected result. And given that, while a message was
stuck in the queue, new messages were happily getting sent, it seems
unlikely to me that the addr lookup was failing.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-12-31 at 09:17 AST, Sam <sam@email-scan.com> wrote:

Jim Diamond writes:

Postfix might require some specific command to retry one or more held
messages immediately.

AIUI (*cough*), that is what "sendmail -q" should do, and (as I think I
mentioned earlier) that has no useful effect whatsoever.

Then the next step up the ladder is DNS resolution. Postfix is not going
to cache DNS queries by itself. If this was anything other than
Slackware

Not necessarily... Slackware is not the only radical distro not using
systemd. Fortunately.

then my next suggestion would be to uninstall systemd-resolved and fix
/etc/ resolv.conf, which never fails to fix these kinds of issues. But, that's not the case here.

Does anything useful get logged to syslog when "sendmail -q" is run,
and no delivery attempts are made.

Nothing at all (at least now when there is nothing in the queue).
Looking at the mail log from the day in question, I see nothing there except

Dec 16 15:06:21 x360 postfix/sendmail[2615]: fatal: usage: sendmail [options]

which is a message that gets written when sendmail is called with (for
example) invalid arguments.

Does Postfix normally log something
for every delivery attempt.

I believe so. Looking at the day in question, I see a number of lines like this over a short time period, which is probably when I was trying
sendmail -q -v
in futility.

Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<xxx>, relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=XXXX type=A: Host not found, try again)

Is there a config setting in Postfix that increases the logging
level.

Good thought.

Yes, there is "debug_peer_level" and "debug_peer_list" which can be tweaked.

Next time this happens I'll crank up debug_peer_level and see what it says.

You want to get to the point where every mail delivery attempt gets
logged, and then see what happens when "sendmail -q" does not do
anything.

All these good ideas (yours and other peoples') almost make me want to
cause the problem to happen again. ;-)

Cheers.
Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

There was a singer in the 80's called Jim Diamond ;)

On Wed, 31 Dec 2025 16:36:34 -0400, Jim Diamond wrote:

You want to get to the point where every mail delivery attempt gets
logged,

they are

All these good ideas (yours and other peoples') almost make me want to
cause the problem to happen again. ;-)

why not, then let it go to see when it actually processes it, it'll be
the mail log, I'm betting 3 days, give or take a few hours :) But if
thats the case you can shorten that time.

I'm sure you have a private email and a freemail a/c, send it to yourself
from one domain to the other.

If you feel adventurous, send two messages, when you get both failing.
get the MID of one of them from "mailq" then try "postsuper -r MID"
and see if it sends, if it does all good, just wait to see how long the
other takes to send.


Happy New Year!

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Jim Diamond <zsd@jdvb.ca> wrote:

On 2025-12-31 at 09:17 AST, Sam <sam@email-scan.com> wrote:

Jim Diamond writes:

Postfix might require some specific command to retry one or more held
messages immediately.

AIUI (*cough*), that is what "sendmail -q" should do, and (as I think I
mentioned earlier) that has no useful effect whatsoever.

Then the next step up the ladder is DNS resolution. Postfix is not going
to cache DNS queries by itself. If this was anything other than
Slackware

Not necessarily... Slackware is not the only radical distro not using systemd. Fortunately.

then my next suggestion would be to uninstall systemd-resolved and fix
/etc/ resolv.conf, which never fails to fix these kinds of issues. But,
that's not the case here.

Does anything useful get logged to syslog when "sendmail -q" is run,
and no delivery attempts are made.

Nothing at all (at least now when there is nothing in the queue).
Looking at the mail log from the day in question, I see nothing there except

Dec 16 15:06:21 x360 postfix/sendmail[2615]: fatal: usage: sendmail [options]

which is a message that gets written when sendmail is called with (for example) invalid arguments.

Does Postfix normally log something
for every delivery attempt.

I believe so. Looking at the day in question, I see a number of lines like this over a short time period, which is probably when I was trying
sendmail -q -v
in futility.

Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<xxx>,
relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3,
status=deferred (Host or domain name not found. Name service error
for name=XXXX type=A: Host not found, try again)

Note, "probably" is not going to help you figure this one out, you need
to be sure which log lines you are looking at relate to exactly when
you try a sendmail -q -v run.

You want to see what is the last line in the log before running
sendmail -q -v, then run it, and see exactly what new lines appear
(you'd preferably do this when you say other email has gone through but
this one is stuck).

The log entry you show says the email was enqueued because at the time
Postfix tried to deliver it, DNS name service lookup for the
destination failed.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2026-01-01 at 09:00 AST, noel <deletethis@invalid.lan> wrote:

There was a singer in the 80's called Jim Diamond ;)

The Scottish guy? Yeah, I remember seeing that some time. If I ever heard
any of his music on the radio I didn't catch his name. I see that all his earthly problems are behind him. :-(

On Wed, 31 Dec 2025 16:36:34 -0400, Jim Diamond wrote:

You want to get to the point where every mail delivery attempt gets
logged,

they are

All these good ideas (yours and other peoples') almost make me want to
cause the problem to happen again. ;-)

why not, then let it go to see when it actually processes it, it'll be
the mail log, I'm betting 3 days, give or take a few hours :) But if
thats the case you can shorten that time.

I'm sure you have a private email and a freemail a/c, send it to yourself from one domain to the other.

If you feel adventurous, send two messages, when you get both failing.
get the MID of one of them from "mailq" then try "postsuper -r MID"
and see if it sends, if it does all good, just wait to see how long the other takes to send.

OK, just for "fun", I
(1) disconnected from my LAN
(2) sent a mail (using mutt) (i.e., "tried to send a mail")
(3) observed the line in /var/log/maillog saying
... status=deferred (Host or domain name not found. Name service
error for name=<MY MAIL SERVER> type=A: Host not found, try again)
(4) reconnected to the network and pinged 8.8.8.8 to make sure I was
able to reach the internet at large
(5) ran sendmail -v -q
... another "status=deferred (Host or domain name not found. ..."
message in maillog.
(6) Ran postsuper, like you suggested
(7) Got another host not found
(8) Ran sendmail -q -v
(9) Praise be! It went out.

For people who like to see all the gory details:
(1)
(2)
Jan 2 11:14:51 x360 postfix/cleanup[7573]: 662881E01AB: message-id=<aVfg66BdOGqwTOZd@x360.localdomain>
Jan 2 11:14:51 x360 postfix/qmgr[2635]: 662881E01AB: from=<jim@my.email.domain>, size=412, nrcpt=1 (queue active)
Jan 2 11:14:51 x360 postfix/smtp[7575]: 662881E01AB: to=<someone@gmail.com>, relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=<MY MAIL SERVER> type=A: Host not found, try again)
(3) <saw the lines above>
(4)
Jan 2 11:15:35 x360 postfix/qmgr[2635]: 662881E01AB: from=<jim@my.email.domain>, size=412, nrcpt=1 (queue active)
Jan 2 11:15:35 x360 postfix/smtp[7575]: 662881E01AB: to=<someone@gmail.com>, relay=none, delay=44, delays=44/0/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=<MY MAIL SERVER> type=A: Host not found, try again)
(5) <saw the lines above>
(6)
Jan 2 11:16:17 x360 postfix/postsuper[7718]: 662881E01AB: requeued
Jan 2 11:16:17 x360 postfix/postsuper[7718]: Requeued: 1 message
Jan 2 11:17:14 x360 postfix/pickup[7617]: 8D12D1E0147: uid=91 from=<jim@my.email.domain> orig_id=662881E01AB
Jan 2 11:17:14 x360 postfix/cleanup[7804]: 8D12D1E0147: message-id=<aVfg66BdOGqwTOZd@x360.localdomain>
Jan 2 11:17:14 x360 postfix/qmgr[2635]: 8D12D1E0147: from=<jim@my.email.domain>, size=513, nrcpt=1 (queue active)
Jan 2 11:17:14 x360 postfix/smtp[7575]: 8D12D1E0147: to=<jim.diamond@gmail.com>, relay=none, delay=143, delays=143/0/0/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=<MY MAIL SERVER> type=A: Host not found, try again)
(7) <saw lines above>
(8)
Jan 2 11:19:55 x360 postfix/qmgr[2635]: 8D12D1E0147: from=<jim@my.email.domain>, size=513, nrcpt=1 (queue active)
Jan 2 11:19:55 x360 postfix/smtp[7937]: 8D12D1E0147: to=<jim.diamond@gmail.com>, relay=<MY MAIL SERVER>[w.x.y.z]:587, delay=304, delays=304/0.02/0.24/0.33, dsn=2.0.0, status=sent (250 OK id=1vbgwY-0000000E8Xh-0sEE)
Jan 2 11:19:55 x360 postfix/qmgr[2635]: 8D12D1E0147: removed
(9)


As I think I mentioned, the times this "stuck email" happened to me was
when I injudiciously shut my laptop immediately after finishing an email.
But now I see that (it seems) I can easily reproduce the problem. So I
guess I can test out all the other suggestions at my leisure.

Happy New Year!

Thanks, you too! (And everyone else who is still using this newsgroup, I
think newsgroup users are on the endangered species list.)

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2026-01-01 at 11:46 AST, Rich <rich@example.invalid> wrote:

Jim Diamond <zsd@jdvb.ca> wrote:

On 2025-12-31 at 09:17 AST, Sam <sam@email-scan.com> wrote:

Jim Diamond writes:

Postfix might require some specific command to retry one or more held >>>> > messages immediately.

AIUI (*cough*), that is what "sendmail -q" should do, and (as I think I >>>> mentioned earlier) that has no useful effect whatsoever.

Then the next step up the ladder is DNS resolution. Postfix is not going >>> to cache DNS queries by itself. If this was anything other than
Slackware

Not necessarily... Slackware is not the only radical distro not using
systemd. Fortunately.

then my next suggestion would be to uninstall systemd-resolved and fix
/etc/ resolv.conf, which never fails to fix these kinds of issues. But, >>> that's not the case here.

Does anything useful get logged to syslog when "sendmail -q" is run,
and no delivery attempts are made.

Nothing at all (at least now when there is nothing in the queue).
Looking at the mail log from the day in question, I see nothing there except

Dec 16 15:06:21 x360 postfix/sendmail[2615]: fatal: usage: sendmail [options]

which is a message that gets written when sendmail is called with (for
example) invalid arguments.

Does Postfix normally log something
for every delivery attempt.

I believe so. Looking at the day in question, I see a number of lines like >> this over a short time period, which is probably when I was trying
sendmail -q -v
in futility.

Dec 16 15:05:58 x360 postfix/smtp[2479]: AA6B21E0B4C: to=<xxx>,
relay=none, delay=0.05, delays=0.03/0.01/0/0, dsn=4.4.3,
status=deferred (Host or domain name not found. Name service error
for name=XXXX type=A: Host not found, try again)

Note, "probably" is not going to help you figure this one out, you need
to be sure which log lines you are looking at relate to exactly when
you try a sendmail -q -v run.

Regrettably, my time machine's flux capacitor broke, and I can only apply carefully-considered educated guesses as to the events of Dec 16. :-)

You want to see what is the last line in the log before running
sendmail -q -v, then run it, and see exactly what new lines appear
(you'd preferably do this when you say other email has gone through but
this one is stuck).

Yup. But failing certainty, I have to go with highly likely.

The log entry you show says the email was enqueued because at the time Postfix tried to deliver it, DNS name service lookup for the
destination failed.

Indeed. And while I am not surprised by the DNS failure when the network
was disconnected, it is the repeated (reported) DNS failures when the
network is up which I find weird.


I do appreciate you pointing me to
address_verify_negative_cache
The documentation for that is:
Enable caching of failed address verification probe results. When
this feature is enabled, the cache may pollute quickly with
garbage. When this feature is disabled, Postfix will generate an
address probe for every lookup.

I find it odd that the default for that is the choice which can cause
the cache to pollute quickly with garbage.

Along with
address_verify_negative_expire_time (default: 3d)

The time after which a failed probe expires from the address
verification cache.

and
address_verify_negative_refresh_time (default: 3h)

The time after which a failed address verification probe needs to
be refreshed.


I can see not wanting to look up a failed address thousands of times a
second, but holding on to a failed probe for three days seems bizarrely
long, unless you are sending mail from (say) Titan to Earth.

Even three hours for the refresh time seems a bit long, but nowhere near as
bad as three days.

Cheers.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

--=_ripper.email-scan.com-1739577-1767400666-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Jim Diamond writes:

OK, just for "fun", I
(1) disconnected from my LAN
(2) sent a mail (using mutt) (i.e., "tried to send a mail")
(3) observed the line in /var/log/maillog saying
... status=deferred (Host or domain name not found. Name service
error for name=<MY MAIL SERVER> type=A: Host not found, try again) (4) reconnected to the network and pinged 8.8.8.8 to make sure I was
able to reach the internet at large
(5) ran sendmail -v -q
... another "status=deferred (Host or domain name not found. ..."
message in maillog.
(6) Ran postsuper, like you suggested
(7) Got another host not found
(8) Ran sendmail -q -v
(9) Praise be! It went out.

Ok, so I distilled the above to: after you regain connectivity the first one or two DNS lookups fail. But, with some persistance, things start working again.

I could ask a few more probing questions here, but I'll cut to the chase: this sounds very similar to a minor problem I have with one of my servers who's sitting behind a cheap-ass router that NATs my LAN to the Intertubes.

The server's running bind in a caching resolver configuration, so DNS
lookups will start with the DNS root, and work their way down the ladder.

The minor problem is: every time I want to push something out to Github, the first git push will crap out because github.com does not resolve. It TEMPFAILs. The second git push will also something fail, and sometimes the third one. After a deep breath, and a "One Mississippi, Two Mississippi, Three Mississippi", github.com starts resolving, and I no longer have any problems pushing and pulling for the rest of that hacking session, which may last an entire afternoon.

There is no temporary connectivity here, in my case: the server is always up and connected. Via that cheap-ass router. Which always brain-farts when initially NAT-ing something on the LAN, for the first time.

Other parts of my LAN that reach the Intertubes via a different path, also via a NAT router but it's a real, living, proper Linux distribution. It's running its own bind, but running on the router itself, with a public IP address, and there's never an issue with that part of my LAN.

I don't think there's anything here for you to tweak. This sounds to me like you have a similar issue. There's probably nothing you can do expect to try
a couple of times, until things start moving again.


--=_ripper.email-scan.com-1739577-1767400666-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaVhk2gAKCRCKYPgoojZS 4q6rAQCsRQqiephEUX9MoQff7CHq0ApxIS7RoDfEd30i8B9eCwEA6+QB2tB50okb rxoTg4q743KdMHNu7khSh/DYy9EZ2QM=
=Gq9d
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-1739577-1767400666-0001--
--- Synchronet 3.21a-Linux NewsLink 1.2