[colug-432] Emailing COLUG list

[R P Herrold]

On Thu, 8 Oct 2009, ***  wrote:

We have a couple of users of gmail getting snagged and tossed 
off the list again.  I post this with the affected 
party's name elided, so that my thinking is not obscure

*** wrote:
> Hmmm, odd...I used to be on the COLUG list as recently as early
> summer.  I had started to wonder why the list traffic had died down,
> and thought it was because of summer.  Then I just stopped thinking
> about it :-).
>
> Could something have happened earlier this year that might have
> dropped my email from the list?  I've resubscribed and will send
> again.

There was an interval where gmail was reacting differently to 
the delays and retries to the greylisting we use, which caused 
many desubscribes for people using gmail provided services.

The executive summary is: google was hammering a single 
mailserver from multiple IP's and giving up in short order on 
delivering email.

This is contrary to the internet historical practice of 
waiting for a bit and retrying for up to five days -- not RFC 
mandated, but what the internet community pre Google designed 
for, and a design that a low capacity receiving host can 
accomodate

Google gmail had the effect of looking like a DDoS attack, and 
frankly .. was

The strawman is: people 'expect' fast email delivery to 
justify the hammering.  Of course people have become 
acculturated to such -- but email was designed to be a 
leisurely medium, and not an instantaneous one.  Certainly 
Google's approach (backed by a funding model) works at the 
expense of harming others load management approaches.

Google (and anyone) have the _capability_ to put all 
connections to a given IP block behind a reverse load 
balancer, which would cause them to not be caught by 
greylists, but they choose not to spend the funds to do so. 
Their choice. but they thereby propose shift their load and 
costs to others.

commercially reasonable but braindead as a member of a 
community.

The milter software maintainer and developer has grafted new 
static 'bad actor' whitelists which include google. These3 are 
periodically updated.  A distributed list approach is really 
the only remote dynamic system I can see that solved the 
problemm well -- the milter system already 'learns' locally 
offered IP's as part of its dynamic passlist model.

It may be that there is a temporary solution with a refresh 
the staic whitelist data with 'the latest and greatest'-- 
there have not been security issues with the milter software 
(which are my usual trigger to work on a system or package).

But at the end of the day, this is Google passing costs on to 
me and that happens when I have spare cycles.  People using 
gmail may decide it is not such a good tool for our mailing 
list [putting to one side the personal privacy concern of the 
implicit exposure of all that is posted into a well-organized 
never-forgetting corpus -- that horse is long since out of the 
barn]

-- Russ herrold