From: rich@example.invalid   
      
   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'.   
      
   >> 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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)