Tuesday June 14th, 2022 NCLUG Meeting

[Bob Proulx]

j dewitt wrote:
> What: Tuesday June 14th, 2022 NCLUG Meeting

The main topic for the meeting tonight was a review of our NCLUG
mailing list.  The mailing list from wihch you are reading this
message.  Because I have been a little frustrated with Google not
accepting *some* messages.

But first we got distracted talking about FreeBSD as a continuation of
the previous email discussion.  I am running FreeBSD as my main
desktop now.  Brain S was asking for some information about how it
works.  I gave a demo of the system and a tour of the pkg binary
package system.

FreeBSD has a few points at which I became stuck and I needed hint to
get past.  For example to get X up and running I had to add a
directive to load the "radeondms" module.  And then with that in place
poof everything worked and X ran with no problem.  For another example
to get the webcam running in the web browser there was another
directive to start up "webcamd" and then that worked with no problem.
FreeBSD has a lot of capability but some things are not obvious and
one must get a hint as to what to do next.  Fortunately there is a lot
of good documentation available.

Then I gave a review of the NCLUG mailing list interaction with
Google's Gmail.  I mentioned it in my previous email message.  Google
is giving a temporary unavailable 421 response to some but not all
messages that are going through the mailing list.  And previously
Google has continued to give the 421 temporary unavailable for days
and days.  At 5 days Postfix on our server will decide the message
will never be delivered and will timeout the delivery sending a bounce
back to Mailman.

These messages all have correct forward-reverse DNS.  Correct SPF
records.  Validating DKIM.  And a DMARC policy declaration.  Bascally
all of the buzzwords that are needed these days.  From different
members discussing the current topics.  Nothing that appears as bulk
mail that would be undesirable.

One thing that would help is if Gmail subscribers would add the
mailing list to their Contacts list.  Google says that this will help
them identify non-spam senders.  It also helps if subscribers read the
mail.  If people delete mail without reading it then Google considers
that sender to be less desirable.  But of course if you are not
reading the mail then you won't be reading this one either.  And if
you are reading this then you already are reading it.  But it is a
factoid just the same.

When Google endlessly gives a 421 temporary failure response then it
will bounce upon timeout and Mailman will take the bounce and
increment the bounce counter for all of the recipients.  The
recipients in this case are all @gmail.com addresses.  If this were a
very busy mailing list then after seven days all of the @gmail.com
addresses would get unsubscribed.  But this is most of the time a
sleepy list and it won't generate enough traffic to have seven
consecutive days of failures.

I had researched this problem and found that the wisdom of the net for
"slow recipients" would be to create a custom transport for "turtles"
(which I found particularly amusing was Google) and then deliver
messages to turtles more slowly.

I modified the turtle examples changing the names from turtle to gmail
and basically set up this configuration.

    gmail unix - - y - - smtp
        -o gmail_destination_concurrency_limit=2
        -o gmail_destination_rate_delay=1s
        -o gmail_destination_recipient_limit=2

Using this transport mapping for that transport.

    gmail.com gmail:

And with that we will see if it has any positive effect.  This message
will be a test of the new configuration.

Brian brought a show-n-tell of his latest smart watch.  This seems to
be the latest and greatest available device yet he was disappointed
that it was not really great to use yet.  Maybe at some point.  At
this time it would be for developers only.

And with that I will send this through and test the configuration
changes hoping that Google will be happier with the slower deliver.