From: zsd@jdvb.ca
On 2026-01-01 at 11:46 AST, Rich wrote:
> Jim Diamond wrote:
>> On 2025-12-31 at 09:17 AST, Sam 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=,
>> 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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
