On Sat, 25 Apr 2015 06:30:10 +0700 Robert Elz <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
