[colug-432] gmail's aggressive spam filters

[R P Herrold]

On Wed, 30 Jan 2013, Rick Hornsby wrote:

> Just a word of caution, if you use gmail - their spam filters seem to be
> getting very aggressive lately.  I've found a handful of valid messages in
> my spam box recently, including Steve's "MediaWiki" list email from a few
> days ago.  This despite that I read from/write to the colug email address
> all the time.

The rules google is using for message marking are simply 
quasi-random.  The SPF record is perfect, the PTR is prefect, 
and so forth

Gmail and google seems to be built on a model of not 
explaining itself nor supporting end users, except on a self 
help model of reading and sifting through the results of a 
google search, and stale articles, not systematically updated

Clearly also gmail does not return notifications of mail it 
has accepted but later decided not to deliver nor drop into a 
spam folder, contrary to RFC 2821 [1] at section 6

Google offers something with 'gmail' but it is not 'email' 
services

> The other big problem I'd have there is that nothing else I've tried, ever,
> can match gmail's search capabilities for finding a long-buried message.

grep on a directory full of mbox's is awfully daggone good, 
and fast

-- Russ herrold

[1] http://asg.web.cmu.edu/rfc/rfc2821.html#sec-6

'6 Problem Detection and Handling

6.1 Reliable Delivery and Replies by Email

     When the receiver-SMTP accepts a piece of mail (by 
sending a "250 OK" message in response to DATA), it is 
accepting responsibility for delivering or relaying the 
message. It must take this responsibility seriously. It MUST 
NOT lose the message for frivolous reasons, such as because 
the host later crashes or because of a predictable resource 
shortage.

     If there is a delivery failure after acceptance of a 
message, the receiver-SMTP MUST formulate and mail a 
notification message. This notification MUST be sent using a 
null ("<>") reverse path in the envelope. The recipient of 
this notification MUST be the address from the envelope 
return path (or the Return-Path: line) ...'