Wazoo Posted August 8, 2005 Share Posted August 8, 2005 http://news.spamcop.net/pipermail/spamcop-...ead.html#103719 Subject Line: [spamCop-List] Re: tekcom & dtag I just tested it with my ISP account: with the option set to accept munged reports, I added my ISP account as a 3rd party address to receive a spam report. It was sent munged, as expected. I then turned on the "refuse munged reports" option for the ISP account, then reported a spam as usual but adding my ISP abuse account as a 3rd party. SC sent the report un-munged, without warning that it would be sent un-munged. So from this single test, it appears that if a reporting address (such as spoof -at- paypal.com) has been registered as an ISP account address with SC, and has set the "refuse munged reports" option for that SC ISP account, then any 3rd party reports sent will silently be sent un-munged. I don't know if there is any way for a SC reporter to check to see if a 3rd party address has been registered as an ISP with SC, and if so whether they accept munged reports or not. Don Wannit This escalated into including the FAQ ..... I sent a query to Don/Deputies .... >spamcop newsgroup >Original title: tekcom & dtag (started 8/4/05) >Jump in point: Don Wannit post - Date: Sat, 06 Aug 2005 11:18:45 -0700 >Message-ID: <dd2uu6$a04$1[at]news.spamcop.net> > >As the story is told, the ISP setting of "only receive >unmunged reports" overrides the reporter's setting >of "send munged reports" ..... > >So the question is .. change in codebase a bug, a >change in philosophy, FAQ needs rewritten ...???? My testing agrees with what the users are saying. I submitted a bug report about it and posted in the .spamcop forum. - Don - (Note: posted into the spamcop newsgroup, unfortunately with the 'no archive' flag, so it's not available in the above referenced archives ... that post provided next ..) I submitted a bug report asking that SpamCop be set to only send unmunged "User Notify" reports if the user's Preferences are set to allow it, or otherwise, to pop-up the standard warning message/dialog box and give the user the opportunity to choose. I suspect the scenario of a user sending a personal report to an abuse address that won't accept unmunged reports wasn't considered when the code was written. - Don - Then RW added a couple of posts: Mike Easter wrote: > Currently the faq sez that mungeing is performed according to reporter > preferences. That has been proven false for the case of additionals. > Ergo the faq is false, a lie, a misrepresentation. Since that is part of the preferences webpage and not a faq, I can't change the wording or post a warning. Technically, the second part is incorrect as well, depending how you read it: "If you select intact spam copies, SpamCop will send all reports unmodified." AFAIK, selecting 'intact' still only affects those that refuse munged reports and means the checkbox on the parsing page is checked by default. Reports to other ISPs who accept munged reports, get munged reports. Richard and a bit further down the thread; Mike has provided most of the right answers, but a little background: ISPs have always had the ability to refuse to accept SpamCop reports. Some major ISPs were starting to do just that because their legal departments were screaming that they couldn't action anonymous complaints. Others were concerned some tampering with headers leaves room for suspicion of other tampering. To prevent the complete refusal of SC reports, Julian entered into a compromise that ISPs could refuse munged reports. Next came the ability to refuse certain types of reports (originating, hosting, relaying, etc.). Finally, when all users were given the option of entering user targeted addresses, ISPs were given the option of refusing those too, because some users were abusing it. Julian also didn't want unmunged reports to be sent by default and want users to be aware the report would be sent unmunged, so he programmed the checkbox to be off by default and use java scri_pt to pop up the warning when the user checked the box. IIRC, the default used to also be that you clicked "cancel" instead of "OK" to keep the box checked, just to make sure the user read the text. Then came along the problem of users that couldn't/wouldn't allow java scri_pt. I foget if it meant they couldn't check the box to send unmunged reports or if it froze the browser, but that is where the default option was put in the user preferences. The intent is, if the user has the preference checked for 'munged only', they get the defaulted off checkbox and popup. If the user has selected 'send unmunged', the box should appear checked by default (therefore no java scri_pt popus to contend with). The problem of sending munged vs unmunged for user notifies is a different problem, but has to do with the order things are done. When parsing, SC checks the ISP account and sees the unmunged only or refusal flag, so can take that into account when displaying the parsing page. SC doesn't know you're going to enter a user notify until you send the data to SC, i.e., hit send. By then it's too late. SC can't come back with an 'are you sure'. It does check the database though and will report back refusals and redirected addresses. I do agree this is an unintentional step in sending unmunged reports to user notifies based on the ISP preferences, but I'm not sure of a way around it. I suppose our easiest option will be to set ISP accounts to 'refuse user notifies' as we come across those that refuse munged reports. Now that I've refreshed the messages and see Don posted, this might all be moot. It may also be the the refuse route is the easiest (and maybe the only) one. Richard Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.