This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Many people who send messages to the mailing list leave the "automatically request a return receipt" turned on when then post a message to the NetBeans mailing lists. My mail reader, sadly, has no option for turning off the "prompt before sending a return receipt" option on a folder-by-folder basis (so it's automatically send a return receipt, or prompt for all). I realize I could do this work on my end, but I think it would be helpful to many people subscribed to the list if it were filtered out before being re-sent by the list.
Sounds reasonable, seems like something a mailing would benefiet from. Collab ?
Granted I've never seen a mail client which won't allow return receipts to be turned off. If someone's organization forces this then they need to setup a free account some where like Yahoo or Google mail and be done with it. These administrative tasks on the client side really are the responsibility of the person choosing to join a list. The Apache lists will simply kick you off the list when you do this type of junk.
Reason I say that is I had issues with my organizations email and it wasn't hard at all to setup a free yahoo account to use in mailing lists. See: http://mail.yahoo.com
My mail client allows me to either automatically send, prompt for all, or never send (and never know the sender wanted a return receipt). I don't think I should have to set up a separate account for the mailing list...
...and that doesn't help prevent people from automatically sending return receipts... I have a procmail rule to strip out return receipt that I use: :0 fhw * ^Disposition-Notification-To: | formail -I Disposition-Notification-To
Relying on the client to be configured correctly is probably a bad idea. In the ideal case all clients would be configured correctly, and all users would know what to do, however we live in the real world :-/ I think bouncing them server-side is a safer option.
I agree that dealing with them on the server-side is the way to go. My procmail rule was intended just to show how easy it is to stip out the header... I think the most frictionless way to go would be to srip out the headers rather than to bounce every mail sent with the header, but either would work for me since it would mean I don't have to see any more return receipts on the list :-).
Assigning to Aniruddha Sarkar for review.
Let me find out from the component owner of the new discussion services, if this is something that is already considered.
I verified with our Discussion Services project owner about this and YES this is something that should get into that. However, in the interim I am trying to determine if we can offer some workaround to handle this. So I need to clarify a couple of things. 1. If we are able to strip out this header, this would be across the entire site; is that acceptable? 2. We are ONLY talking about "return-receipt" here, right? 3. Currently when such "return-receipts" are set and users *inadvertently* send the return recipts, do those go back to the "requesting user(s)" or they are sent to the "reply-to" address, which could be the mailing list itself?
Updating SWB.
I can't say whether stripping it across the netbeans.org domain is a good thing or not. I'd say for sure we don't want them on the lists. I'm only talking about return receipts here (stripping the "Disposition-Notification-To" header). The inadvertant return receipts seem to go to the list, which makes them even more bothersome. Thanks for looking at this.
RE question 1. - yes, accross the entire site is fine. I can't imagine any list where ppl would want to see return receipts. RE: "stripping out headers" - do you mean remove the header that requests a return receipt ? Makes sense.
We need a bit of clarification on my question #3. I seriously doubt if the read-recipt is going back to the mailing list. If that is not the case then I am not seeing that behavior myself. To test this I used MS Outlook and added the read-recipt to an outgoing mail. I do see within the raw-header, the "Disposition-Notification-To" one. But it is correctly set to Disposition-Notification-To: "Aniruddha Sarkar" <asarkar@collab.net>. Hence *even* if the receiving users open the e-mail and *inadvertently* send the read-recipt(s) (as I did in my test), it should not go to the mailing list. As a matter of fact it should not use CEE at all for this receipt (unless the requesting user has a @netbeans.org address). So, my initial assumption that the return recipts are going to the mailing lists was wrong (please confirm). However, it is true that we need to strip this "Disposition-Notification-To" header out of the mailing list(s) completely. We are investigating ino that.
I agree that it doesn't seem that the return receipt *should* go to the lists, but it seems that they sometimes do -- a broken MUA, maybe? See http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=66721 for just one example.
The message that instigated the return receipt message I mentioned in my previous reply is here: http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=66706&raw=true The Disposition-Notification-To: header *is* present, and it is set to the *original sender* (not the list) as you said, so it does appear that the return receipts sent to the list are actually caused by broken mail clients. Even still, it would probably be best to strip them out. Thanks again for looking into this.
Crued, Thanks for pointing me to the 2nd message. To clarify, I think what happened was that the first poster(Mauricio)set the Disposition-Notification-To in his post. All the users replied to this post till 3/25 did not trigger any return-reciepts to the list itself(whether or not they had the read-notification alert set to ON or OFF on their mail client). However, on 2006-03-26, mstevlik@gamo.sk posts a message to the list that appears to be a return-recipt. That is not supposed to happen as per the disposition-notification-to header which explicitly was set to: "Mauricio" <mauricio@infsr.unijui.tche.br>. While, yes, we need to remove this header from the mailing lists, I am wondering if this is triggered as a result of a buggy e-mail client that mstevlik@gamo.sk used top open this e-mail! Please let me know if you notice any other occurences of this retrun-reciepts going to the mailing list(s).
We have verified that adding "disposition-notification-to" to the remove-list in the configuration file will create new mailing lists with that option. That is, emails sent with the read-receipt turned ON will get that header stripped. We will try to roll out this feature change in the Danube-S upgrade. NOTE: After rolling out this change, ONLY newly created lists will have this feature. Existing lists will still have this option missing; hence any e-mails with read-recipts to those lists will not get the header stripped. We are verifying if we can run a script that will make this change to all the lists' configuration files. While we try that out, is it possible to get the top 10 mailing lists that would benefit from this change? We can at least make manual changes to those lists for immediate measures.
Updating Target Milestone.
www lists: nbusers nbdev nbdiscuss nbannounce nbweekly nbui nbj2ee nbdiscuss_ru nbdiscuss_fr nbdiscuss_zh not www lists : dev@openide Thanks.
Hi Jack, As per your request we have made the necessary changes to the 11 mailing lists. Please let us know if it would be possible for you to verify this on your end, or we should send some test e-mails to verify it ourselves. I did not want community members to get a read-receipt e-mail from CollabNet :) As for making this feature permanent, that is, for *all* exisiting and future mailing lists, CollabNet's engagement team will review this requirement after the Danube-S upgrade. The change will require some changes in the core product, hence this decision. Thanks
Bringing it back to the Support Queue for the visibility.
Thanks sripriya. Crued, do you notice return-receipts on nbusers@ (or the other lists this was applied to) anymore ?
I removed my procmail filter shortly after askar's message on Apr 19 was posted. Since then, I don't recall seeing a return receipt from a netbeans.org mailing list. Also, I haven't seen any return receipts sent to any of the lists. The problem seems to have been corrected. Thanks.
Jack, So shall we close this as fixed then? Thanks, Priya
Well the long term issue is still in progress, right ? > As for making this feature permanent, that is, for *all* exisiting and future > mailing lists, CollabNet's engagement team will review this requirement after > the Danube-S upgrade. The change will require some changes in the core > product, hence this decision. So this issue should stay open to track that, I think.
This has been fixed in the inst set of CEE 4.5.2, Marking the issue as Resolved Later as this issue will be reviewed by Support once the site is upgraded. Regards, Ramya Support operations
Hi This feature is fixed in Rubicon and I have verified the same on a test box carrying the latest version. I shall close this case for now. Please feel free to re-open, if the functionality does not satisfy your expectation when site gets upgraded to Rubicon version of CEE. Regards, Vathsan Support Operations.
Marking the issue as Resolved FIXED.
We recently moved out from Collabnet's infrastructure