Summary: | Gentoo-announce not synchronised or synchronised with delays to published GLSas and Portage metadata | ||
---|---|---|---|
Product: | Gentoo Infrastructure | Reporter: | Sabahattin Gucukoglu <mail> |
Component: | Mailing Lists | Assignee: | Gentoo Infrastructure <infra-bugs> |
Status: | RESOLVED REMIND | ||
Severity: | normal | CC: | security |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://security.gentoo.org/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sabahattin Gucukoglu
2007-03-19 06:40:14 UTC
Thanks for your report. I confirm there are some email loss... and it's indeed confusing. As a summary, there are two situations: - emails hitting certain recipients of -announce but not all of them. We don't re-send GLSAs in that case, or some recipients will have the email twice. We may change this policy if we have users feedback. It happens ~ 20% of the time. - emails *apparently* never hitting -announce, or emails really not hitting g-announce and we don't even receive the moderation request (g-announce is indeed moderated). In that case we resend the GLSA later. Recently, it was the case of GLSA-200703-13 and GLSA-200703-15. (In reply to comment #1) > Thanks for your report. I confirm there are some email loss... and it's indeed > confusing. > As a summary, there are two situations: These essentially explain what I'm seeing, thanks! > - emails hitting certain recipients of -announce but not all of them. We don't > re-send GLSAs in that case, or some recipients will have the email twice. We > may change this policy if we have users feedback. It happens ~ 20% of the time. Does anyone know exactly how bad this lossage is? I mean, what metrics are in the MTA or MLM running the list which might explain such a thing? Can someone find the lists of addresses which bounced and caused the distribution to somehow fail? This sounds fishily like a case of if-only-I-had-the-darn-logs syndrome. I know it's a sendmail with mlmmj (and I'm wondering how they managed to add verp then). But it seems to me that the problem itself is findable and fixable and that the postmaster shouldn't be happy until it is. It's rather odd. > - emails *apparently* never hitting -announce, or emails really not hitting > g-announce and we don't even receive the moderation request (g-announce is > indeed moderated). In that case we resend the GLSA later. Recently, it was the > case of GLSA-200703-13 and GLSA-200703-15. Right, I chanced upon 200703-15 which prompted me to start this bug. Thanks for your attention. (In reply to comment #2) > (In reply to comment #1) > > Thanks for your report. I confirm there are some email loss... and it's indeed > > confusing. > > As a summary, there are two situations: > > These essentially explain what I'm seeing, thanks! > > > - emails hitting certain recipients of -announce but not all of them. We don't > > re-send GLSAs in that case, or some recipients will have the email twice. We > > may change this policy if we have users feedback. It happens ~ 20% of the time. > > Does anyone know exactly how bad this lossage is? I mean, what metrics are in > the MTA or MLM running the list which might explain such a thing? Can someone > find the lists of addresses which bounced and caused the distribution to > somehow fail? This sounds fishily like a case of if-only-I-had-the-darn-logs > syndrome. I know it's a sendmail with mlmmj (and I'm wondering how they > managed to add verp then). But it seems to me that the problem itself is > findable and fixable and that the postmaster shouldn't be happy until it is. > It's rather odd. VERP info: http://dev.gentoo.org/~lcars/misc/sendmail-hacks.txt (it's also in README.sendmail inside mlmmj tarball) It is not a "findable and fixable" problem, or at least it's not that trivial. The postmaster (me) spend *many* hours trying to find the issue without luck, and I assure that it's not trivial and no, I'm not happy. We will consider using a different software if we cannot track down the bug soon, I'm currently no longer involved in mlmmj management so maybe the new admin will have better luck. (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Thanks for your report. I confirm there are some email loss... and it's indeed > > > confusing. > > > As a summary, there are two situations: > > > > These essentially explain what I'm seeing, thanks! > > > > > - emails hitting certain recipients of -announce but not all of them. We don't > > > re-send GLSAs in that case, or some recipients will have the email twice. We > > > may change this policy if we have users feedback. It happens ~ 20% of the time. > > > > Does anyone know exactly how bad this lossage is? I mean, what metrics are in > > the MTA or MLM running the list which might explain such a thing? Can someone > > find the lists of addresses which bounced and caused the distribution to > > somehow fail? This sounds fishily like a case of if-only-I-had-the-darn-logs > > syndrome. I know it's a sendmail with mlmmj (and I'm wondering how they > > managed to add verp then). But it seems to me that the problem itself is > > findable and fixable and that the postmaster shouldn't be happy until it is. > > It's rather odd. > VERP info: http://dev.gentoo.org/~lcars/misc/sendmail-hacks.txt > (it's also in README.sendmail inside mlmmj tarball) Wa? You are sick! :-) (but it's damned impressive, all the same) > It is not a "findable and fixable" problem, or at least it's not that trivial. > The postmaster (me) spend *many* hours trying to find the issue without luck, > and I assure that it's not trivial and no, I'm not happy. We will consider > using a different software if we cannot track down the bug soon, I'm currently > no longer involved in mlmmj management so maybe the new admin will have better > luck. My choice of MLM is ecartis (not yet in tree) which understands DSN (so, if you're still with sendmail or move to postfix, this may be a nice choice). Right, well, otherwise there is nothing more to do until some change happens to lists.gentoo.org (which is probably of more interest to the other users of the listserver) so I think probably we resolve this bug as Remind. Thanks (and good luck to current postmaster, seems like it's in good hands). i disagree with closing that bug since it's really a worrying issue... err, we already have lots of difficult open bugs waiting for a fix. (In reply to comment #5) > i disagree with closing that bug since it's really a worrying issue... err, we > already have lots of difficult open bugs waiting for a fix. It is a worrying issue, but it's for infrastructure and potentially affects more than gentoo-announce. I've marked as remind because I don't think much more can be done right now, and security team isn't the problem - listmanager and mailer configuration is. So we should be coaching for users to even be aware that a mail delivery problem exists (and if any new bug gets opened on that, please CC me it). If this bug attracts enough attention then it may make sense to reopen it, because it's only been until now a bug relating to mail loss (as far as I've managed to tell) has been filed, and although I agree it's a problem no-one else has been bothered enough to mention it if they ever thought much of it (I nearly didn't). So the more interesting question related specifically to the GLSas is ... is any likely short-term recommendation forthcoming, do you think? Does it make sense to broadcast this possible problem to gentoo-announce (or elsewhere) and have everyone check just how many security bugs they've been missing and just how bad the situation is? Because that's precisely what's pertinent to this bug and that's really the thing I'm most bothered about - people having not got all their fixes because they've not even been aware of them. I routinely don't have access to a web browser. And in avoiding the problems of mail loss, how about alternative channels for GLSAs - ATOM feed, perhaps? |