From: zsd@jdvb.ca
On 2025-12-29 at 14:06 AST, Rich wrote:
> Jim Diamond wrote:
>> On 2025-12-28 at 01:19 AST, Rich wrote:
>>> Jim wrote:
>>>> On 2025-12-25 at 22:13 AST, noel 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=, size=2073, nrcpt=1 (queue active)
>>>>>> Dec 16 15:06:17 x360 postfix/smtp[2479]: AA6B21E0B4C:
>>>>>> to=, 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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
