Re: [Nmh-workers] Stanford disliking my emails -- update + question

[Bob Carragher]

On Sat, 25 Apr 2015 06:30:10 +0700 Robert Elz <address@hidden> sez:

[...]
> I would also note that it is possible it is the mailing list exploder on
> nongnu,org that's doing it - detecting a To/Cc header with an address that's
> also on the list, and dropping that address from the list expansion.  That
> would be (just slightly) less broken than having the receiving MTA drop
> a message because it assumes a later one will arrive, and I'd actuually
> give a higher probability than the "gmail hid it" hypothesis.

Andy's experiment makes this look like the likely explanation.

At least, it doesn't appear that GMail's doing it, which is a
huge relief for me!

[...]
> Incidentally, the reason for the delay is most likely a local problem here,
> mail to gmail would normally be transferred over an IPv6 connection, but
> someone local has installed some broken firewall (or something) that is
> affecting SMTP over IPv6 in weird ways - connection attempts start to work,
> late enough that sendmail doesn't fall back to other addresses, but without
> allowing messages through.  The copy that was delivered eventually went via
> IPv4, so v6 must have been (for whatever reason) even more down at that
> instant, preventing even the SNY/SYN-ACK from succeeding, and allowing
> fall back to gmail's v4 addresses.   In any case, this isn't something to
> blame on Stanford's, or gmail's, spam filtering...   This issue is known
> here, and being worked upon, it just isn't fixed yet...

Yay!  One less (email) problem for me to need to deal with!  B-)





On Fri, 24 Apr 2015 19:50:01 -0400 Ken Hornstein <address@hidden> sez:

> >I would also note that it is possible it is the mailing list exploder on
> >nongnu,org that's doing it - detecting a To/Cc header with an address that's
> >also on the list, and dropping that address from the list expansion.  That
> >would be (just slightly) less broken than having the receiving MTA drop
> >a message because it assumes a later one will arrive, and I'd actuually
> >give a higher probability than the "gmail hid it" hypothesis.
> 
> That is possible, but I've personally received duplicate messages from the
> mailing list and a local copy, and having nongnu.org delete a message it
> thinks is duplicate strikes me as broken as well.  Would be interesting
> if we could see what happened on the gmail side.

I also used to receive duplicate messages, and also copies of
messages that *I* sent -- not only from this mailing list but
also from others (like the problematic Stanford ones).  Did some
listserv update go out in the recent past that suppresses this
behavior?  (I prefer seeing them, as they function as nice
"ack"s, though I can believe that that's a minority opinion in
the wide world.)





On 24 Apr 2015 17:57:01 -0600 "Andy Bradford" <address@hidden> sez:

> Thus said Robert Elz on Sat, 25 Apr 2015 06:30:10 +0700:

[...]

> > His concern  was the delay  - he'd seen replies  to a message  that he
> > didn't receive  for days (and if  I'd noticed the holdup,  and dropped
> > that copy of  the message - expecting him to  receive, or have already
> > received, a copy via the list - might never have seen).
> 
> I see. The concern was the delay (which at the time probably looked like
> 100% delivery failure),  not the duplicate removal.  Personally, I don't
> mind delay---SMTP was designed  for reliable delivery, not instantaneous
> delivery. On the  other hand, a mail system  that ``removes duplicates''
> seems to break the reliability of the system.

Actually, before I finally received a copy, I was concerned that
I would *never* see that message.  Both are ultimately concerns.
(Is the MLM not delivering all postings?  Is there a new problem
delaying emails to me?)  But it looks like only the former is a
(potential) problem.

                                Bob