Received: from stpeter.im (stpeter.im [207.210.219.233]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6TGk6v3000783 for ; Wed, 29 Jul 2009 09:46:11 -0700 Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3FCBD4007B; Wed, 29 Jul 2009 10:07:44 -0600 (MDT) Message-ID: <4A7073CE.9070904@stpeter.im> Date: Wed, 29 Jul 2009 18:07:42 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> <4A6E9125.4080908@dcrocker.net> In-Reply-To: <4A6E9125.4080908@dcrocker.net> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:38:17 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 29 Jul 2009 09:46:11 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 16:46:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/28/09 7:48 AM, Dave CROCKER wrote: > > Steve Atkins wrote: >> Both IODEF >> and ARF are designed primarily for solicited reports between >> cooperating parties. If you're sending unsolicited messages, you're >> outside the main use case for either. > > > I think this distinction between solicited and unsolicited reports is not touted > vigorously enough, especially in terms of what should or does make the > interaction mechanisms different. > > At the least, I am thinking of being part of an explicit trust infrastructure, > versus not. BTW, we have been working on an incident reporting technology for the Jabber network (I suppose that IM is a form of messaging, so we might use ARF), and a draft is here: http://xmpp.org/extensions/xep-0268.html Our initial thinking is that each deployed server would have a list of "buddies" (peer servers) with which it would share incident reports. What a server would do with unsolicited reports (i.e., reports from peers not on its "buddy list") is yet undefined. In any case, we hope to learn from the experience of email operators while we hone the approach we've started to define in our community. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwc84ACgkQNL8k5A2w/vwT1gCcCpUzZXmy9ebN/RFZN+u6UDWc QFEAmgN4e/e1kT+3BBWGZD3w4fotvWdB =APxZ -----END PGP SIGNATURE----- Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6TFXFvh028373 for ; Wed, 29 Jul 2009 08:33:21 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 29 Jul 2009 17:33:06 +0200 id 00000000005DC031.000000004A706BB3.00003159 Message-ID: <4A706BB6.5080805@tana.it> Date: Wed, 29 Jul 2009 17:33:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Yakov Shafranovich References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6F0989.6000507@tana.it> <501c18e00907280849t3384ac7fj624476b5b329710e@mail.gmail.com> In-Reply-To: <501c18e00907280849t3384ac7fj624476b5b329710e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 29 Jul 2009 08:33:21 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] More Feedback-Types X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 15:33:21 -0000 Yakov Shafranovich wrote: > On Tue, Jul 28, 2009 at 11:42 AM, Steve > Atkins wrote: >> On Jul 28, 2009, at 7:22 AM, Alessandro Vesely wrote: >>> As for the values of those headers, I'd propose a few additions: >>> >>> * spf-softfail >>> This allows postmasters of a domain whose SPF record is suitably set >>> to monitor how many messages are being sent without using the relevant >>> SUBMIT servers. Naive forwarding will probably add noise, which may >>> may be filtered out by looking at the Received headers. >> This seems to be of minimal value to the recipient of the ARF report >> and of zero value to the sender of the ARF report, which makes it >> unlikely it would be used. Adding functionality without a clear, wide >> use case just makes the spec more complex without adding value >> to match. Steve's point may be correct. RFC 4408 mentions the possibility of feedback, but not automated reporting, nor ARF. In case softfail's behavior will be changed in a future SPF RFC, it may define the relevant Feedback-Type as well. > There is a basic design principle behind ARF that the second part of > the report should not replicate any data not already found in the > attached email message. SPF soft fail would be indicated via the > appropriate header in the message itself. Generally, the focus on > fields in the second part is for data that would not be otherwise > derived from the email message itself. While that envisages a sanely orthogonal data representation, the Feedback-Type is special as it explains the _reason_ why a report is submitted. The reason should be sufficient to determine how report's destinations can be found. Routing decisions of this kind may be made by the report originator as well as by subsequent recipients. The Abusix's database described by Tobias is an example of getting email addresses by IP addresses. Relevant ISPs, e.g. the local Telecom's abuse desk, should then forward reports to the relevant ESPs, e.g. a company's network facilities group. Extracting data from a report, i.e. _consuming_ it, is a completely different activity than _routing_ it. In general, there may be multiple parties interested in a report about a specific message. Target addresses can be found in a number of ways, but it may be easier to program their gathering when a list of reporting reasons is available. Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6SFnmol029979 for ; Tue, 28 Jul 2009 08:49:53 -0700 Received: by wa-out-1112.google.com with SMTP id k34so17713wah.19 for ; Tue, 28 Jul 2009 08:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.46.5 with SMTP id h5mr4802601vcf.28.1248796187569; Tue, 28 Jul 2009 08:49:47 -0700 (PDT) In-Reply-To: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6F0989.6000507@tana.it> From: Yakov Shafranovich Date: Tue, 28 Jul 2009 11:49:27 -0400 Message-ID: <501c18e00907280849t3384ac7fj624476b5b329710e@mail.gmail.com> To: Steve Atkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 28 Jul 2009 08:49:53 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] More Feedback-Types X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:49:53 -0000 On Tue, Jul 28, 2009 at 11:42 AM, Steve Atkins wrote: > > On Jul 28, 2009, at 7:22 AM, Alessandro Vesely wrote: >> >> As for the values of those headers, I'd propose a few additions: >> >> * spf-softfail >> This allows postmasters of a domain whose SPF record is suitably set >> to monitor how many messages are being sent without using the relevant >> SUBMIT servers. Naive forwarding will probably add noise, which may >> may be filtered out by looking at the Received headers. > > This seems to be of minimal value to the recipient of the ARF report > and of zero value to the sender of the ARF report, which makes it > unlikely it would be used. Adding functionality without a clear, wide > use case just makes the spec more complex without adding value > to match. > There is a basic design principle behind ARF that the second part of the report should not replicate any data not already found in the attached email message. SPF soft fail would be indicated via the approriate header in the message itself. Generally, the focus on fields in the second part is for data that would not be otherwise derived from the email message itself. (yes, I know about DKIM) Yakov Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6SFgScH029648 for ; Tue, 28 Jul 2009 08:42:33 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 485328022B for ; Tue, 28 Jul 2009 08:42:11 -0700 (PDT) Message-Id: From: Steve Atkins To: ARF mailing list In-Reply-To: <4A6F0989.6000507@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 08:42:26 -0700 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6F0989.6000507@tana.it> X-Mailer: Apple Mail (2.935.3) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 28 Jul 2009 08:42:33 -0700 (PDT) Subject: Re: [feedback-report] More Feedback-Types X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:42:33 -0000 On Jul 28, 2009, at 7:22 AM, Alessandro Vesely wrote: > John R. Levine wrote: >> The question is still open whether you'd make a combo report of >> everything >> you don't like about the message and send it to all of the >> responsible >> parties, or you'd send different reports pointing out the >> individual bits >> that each reportee is supposed to deal with. > > That nicely puts the question of what email addresses are the correct > targets for those reports. However, a single ARF report is allowed a > single Feedback-Type, according to the current draft. What if the same > message is simultaneously an abuse, a fraud, and fails DKIM? It seems > a futile waste of bandwidth to have to transmit it many times. In case > the target address is the same, couldn't it be possible to place as > many Feedback-Type headers as needed? Specific incompatibilities, if > any (e.g. between abuse and non-spam?), should then be individually > listed. > > As for the values of those headers, I'd propose a few additions: > > * dropbox > As suggested by Rick, this is not exactly the same as a fraud. Help > desks should consider it even if the message didn't originate from > their mailouts, and monitor the volume of relevant incoming traffic. This is already covered by the Reported-URI: field. If someone wants to tweak the wording to make that clearer, that'd be fine, but it's existing functionality. The feedback-type is declaring (loosely) what you object to about the message. The Reported-URI field is one specific element of the message that you believe the recipient of the report should be aware of. Phish with a dropbox? Feedback-Type: fraud Reported-URI:mailto:dropbox@example.com Spam with a dropbox? Feedback-Type: abuse Reported-URI:mailto:dropbox@example.com > > * test > This may be useful, especially in case ARs are sent indirectly. For > example, sending indirectly through a vouching service allows the > latter to monitor a vouched ESP's reaction. Small ESPs will not want > to risk worsening their reputation just to check the feedback loop. > (Or is this what non-spam has been provided for?) Possibly. Or maybe "other". When ARF is used between consenting participants they can certainly agree to use one of those two types for test messages sent during the setup of a feedback loop or similar. I can see that this would be convenient for FBL subscribers at least, and it'd be nice of FBL providers offered such a thing, but I don't think we need to extend the existing spec for that to be possible. > > * spf-softfail > This allows postmasters of a domain whose SPF record is suitably set > to monitor how many messages are being sent without using the relevant > SUBMIT servers. Naive forwarding will probably add noise, which may > may be filtered out by looking at the Received headers. This seems to be of minimal value to the recipient of the ARF report and of zero value to the sender of the ARF report, which makes it unlikely it would be used. Adding functionality without a clear, wide use case just makes the spec more complex without adding value to match. We have the catch-all "other" for people to use if they want to setup private, edge-case uses while still sending "valid" ARF format reports. (If one of those edge case uses actually gets some traction, then that'd be the time to revisit whether we can extend the spec to assist it). > * opt-in > Since there is already an opt-out, an opt-in should be sent timely to > acknowledge that a user has subscribed to a newsletter, list or other > serial transmission. The recipient should just register the event, as > it may have legal relevance, but may take further action according to > user options. An opt-out is an opt-out of receiving "further messages like this one". There is no equivalent message about which an "opt-in" report could be sent that really makes sense. If the message you were sending it about were one of the messages to which you'd opted-in, then feedback-type "not-spam" would seem to fit, though I don't think ARF is really a great format for electronic notarization. Cheers, Steve Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6SF2MkQ027387 for ; Tue, 28 Jul 2009 08:02:27 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 28 Jul 2009 16:22:02 +0200 id 00000000005DC037.000000004A6F098A.00000AEB Message-ID: <4A6F0989.6000507@tana.it> Date: Tue, 28 Jul 2009 16:22:01 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ARF mailing list References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:40:19 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 28 Jul 2009 08:02:27 -0700 (PDT) Subject: [feedback-report] More Feedback-Types X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:02:32 -0000 John R. Levine wrote: > The question is still open whether you'd make a combo report of everything > you don't like about the message and send it to all of the responsible > parties, or you'd send different reports pointing out the individual bits > that each reportee is supposed to deal with. That nicely puts the question of what email addresses are the correct targets for those reports. However, a single ARF report is allowed a single Feedback-Type, according to the current draft. What if the same message is simultaneously an abuse, a fraud, and fails DKIM? It seems a futile waste of bandwidth to have to transmit it many times. In case the target address is the same, couldn't it be possible to place as many Feedback-Type headers as needed? Specific incompatibilities, if any (e.g. between abuse and non-spam?), should then be individually listed. As for the values of those headers, I'd propose a few additions: * dropbox As suggested by Rick, this is not exactly the same as a fraud. Help desks should consider it even if the message didn't originate from their mailouts, and monitor the volume of relevant incoming traffic. * test This may be useful, especially in case ARs are sent indirectly. For example, sending indirectly through a vouching service allows the latter to monitor a vouched ESP's reaction. Small ESPs will not want to risk worsening their reputation just to check the feedback loop. (Or is this what non-spam has been provided for?) * spf-softfail This allows postmasters of a domain whose SPF record is suitably set to monitor how many messages are being sent without using the relevant SUBMIT servers. Naive forwarding will probably add noise, which may may be filtered out by looking at the Received headers. * opt-in Since there is already an opt-out, an opt-in should be sent timely to acknowledge that a user has subscribed to a newsletter, list or other serial transmission. The recipient should just register the event, as it may have legal relevance, but may take further action according to user options. Received: from [10.43.1.48] ([77.241.97.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6S5mO7k025972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 22:48:33 -0700 Message-ID: <4A6E9125.4080908@dcrocker.net> Date: Tue, 28 Jul 2009 07:48:21 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Steve Atkins References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> In-Reply-To: <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 27 Jul 2009 22:48:34 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 05:48:34 -0000 Steve Atkins wrote: > Both IODEF > and ARF are designed primarily for solicited reports between > cooperating parties. If you're sending unsolicited messages, you're > outside the main use case for either. I think this distinction between solicited and unsolicited reports is not touted vigorously enough, especially in terms of what should or does make the interaction mechanisms different. At the least, I am thinking of being part of an explicit trust infrastructure, versus not. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from [10.43.1.48] ([77.241.97.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6S5jhAi025854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 22:46:19 -0700 Message-ID: <4A6E9081.80605@dcrocker.net> Date: Tue, 28 Jul 2009 07:45:37 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tobias Knecht References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> <4A6DC517.7020807@knutix.de> <4A6DDBC7.8080906@knutix.de> In-Reply-To: <4A6DDBC7.8080906@knutix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 27 Jul 2009 22:46:20 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 05:46:20 -0000 Tobias Knecht wrote: > But if I interpret the feedback on this list right, I'm not dogmatic > enough, more pragmatic and more solution driven. The IETF makes decisions based on "rough consensus". That means that one must develop support from many others in the community. You might want to consider whether your discussion style is conducive to satisfying that requirement. d/ ps. Please note that I am not stating whether I think your assessment is correct or not, merely whether it is productive to communicate it to the folks on this list. Indeed, most of us are sons of bitches; it's only a question of how it manifests. But really, do you think we like to be reminded of it? -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RLLInL031582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 27 Jul 2009 14:21:23 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 27 Jul 2009 14:21:17 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich , Steve Atkins Date: Mon, 27 Jul 2009 14:21:16 -0700 Thread-Topic: [feedback-report] The limits of ARF, and INCH Thread-Index: AcoO+G08yWtZxSaTQdCQtvc+zLQEWwAB6m2A Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> <4A6DDBE3.1090005@knutix.de> <81AD8A1A-AE5D-4AF7-BAB1-ED1B3193B1EB@word-to-the-wise.com> <501c18e00907271323o7e8b81bbn5433217524285736@mail.gmail.com> In-Reply-To: <501c18e00907271323o7e8b81bbn5433217524285736@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 14:21:24 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n6RLLInL031582 Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 21:21:24 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Yakov Shafranovich > Sent: Monday, July 27, 2009 1:24 PM > To: Steve Atkins > Cc: ARF mailing list > Subject: Re: [feedback-report] The limits of ARF, and INCH > > Early on there was talk about aggregate feeds. Microsoft offers > something along those lines with SNDS: There's also the recently-added "Incidents:" field which is meant to indicate "this report actually represents X cases, of which this is an example". Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RKO32c027795 for ; Mon, 27 Jul 2009 13:24:09 -0700 Received: by qw-out-2122.google.com with SMTP id 5so1694827qwi.39 for ; Mon, 27 Jul 2009 13:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.77.84 with SMTP id f20mr4108284vck.109.1248726243099; Mon, 27 Jul 2009 13:24:03 -0700 (PDT) In-Reply-To: <81AD8A1A-AE5D-4AF7-BAB1-ED1B3193B1EB@word-to-the-wise.com> References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> <4A6DDBE3.1090005@knutix.de> <81AD8A1A-AE5D-4AF7-BAB1-ED1B3193B1EB@word-to-the-wise.com> From: Yakov Shafranovich Date: Mon, 27 Jul 2009 16:23:43 -0400 Message-ID: <501c18e00907271323o7e8b81bbn5433217524285736@mail.gmail.com> To: Steve Atkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 13:24:09 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 20:24:09 -0000 On Mon, Jul 27, 2009 at 1:06 PM, Steve Atkins wrote: > On Jul 27, 2009, at 9:54 AM, Tobias Knecht wrote: > > >> >>> Perhaps you should talk to the ISPs first, rather than just sending >>> them unsolicited mail and waiting for complaints? Both IODEF >>> and ARF are designed primarily for solicited reports between >>> cooperating parties. If you're sending unsolicited messages, you're >>> outside the main use case for either. >> >> Seems a little bit odd to me to ask for permission to complain about >> illegal abusive behavior. > > The abuse@ alias is intended for individual reports. At many ISPs it's > read entirely manually, with minimal automation. > > If you misuse it by, for example, sending 116 complaints about a > single incident within a five minute period, then you're going to > overwhelm the abuse desk procedures. > Early on there was talk about aggregate feeds. Microsoft offers something along those lines with SNDS: https://postmaster.live.com/snds/index.aspx Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RIFipr017858 for ; Mon, 27 Jul 2009 11:15:50 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.100]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVUjg-0007KH-35; Mon, 27 Jul 2009 20:15:44 +0200 Message-ID: <4A6DEECF.7050602@knutix.de> Date: Mon, 27 Jul 2009 20:15:43 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Steve Atkins References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> <4A6DDBE3.1090005@knutix.de> <81AD8A1A-AE5D-4AF7-BAB1-ED1B3193B1EB@word-to-the-wise.com> In-Reply-To: <81AD8A1A-AE5D-4AF7-BAB1-ED1B3193B1EB@word-to-the-wise.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8D5546B9CE82DDD51210AB75" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248718550;f8f13c0e; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 11:15:50 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 18:15:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8D5546B9CE82DDD51210AB75 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> Perhaps you should talk to the ISPs first, rather than just sending >>> them unsolicited mail and waiting for complaints? Both IODEF >>> and ARF are designed primarily for solicited reports between >>> cooperating parties. If you're sending unsolicited messages, you're >>> outside the main use case for either. >> Seems a little bit odd to me to ask for permission to complain about >> illegal abusive behavior. >=20 > The abuse@ alias is intended for individual reports. At many ISPs it's = =20 > read entirely manually, with minimal automation. I would not agree with the intent just for individual reports, but I agree with the manually handling of them. Right. > If you misuse it by, for example, sending 116 complaints about a =20 > single incident within a five minute period, then you're going to =20 > overwhelm the abuse desk procedures. 1.) We can not decide on our side if it is a single incident. For example a lot of Russian or Middle East dial-up ISPs use NAT. So how could we know if it is a single incident? 2.) I know about 20 organizations or ISPs which are preparing to report their honeypot and spamtrap hits in the same way. Lets say we do not think about the first argument and send 3 mails per hour per incident. Then they would get at least 60 reports per hour. Which would be too much for a lot of abuse departments and their manual handling. 3.) We know ISPs which are locking customers after the 3rd report from us. And they have absolutely no problem with us. Cause the faster they get their problem solved, the less reports they receive. So the only thing we are doing, we give the ISP the opportunity to use our data. We do not recommend it. > If you do that, there are three things that the abuse desk can do. >=20 > 1. The abuse desk never catches up, and becomes ineffective due to = > the volume. That's the situation when they decide to do number 2 or 3. Which is not to bad, 'cause they do something. > 2. The abuse desk puts some ad-hoc automation in place to extract =20 > what little data there is in the mailbomb. Is that bad? They put some automation together and hopefully handle their abuse issues more efficient in future. Or handle them faster. Like a lot of ISP already do. I'm happy to be the bad guy, if they get better and stop their abusive behavior faster, than before. > 3. The abuse desk puts some filtering in place to ensure that the =20 > sender of the high volume messages doesn't end up in the abuse queue. Good. Not a problem for us. We do not recommend using our data. Funny thing is, 6 big US ISPs used our data for 2 month. One did not and blocked us. We saw the reports rates and they were decreasing at all 6 ISPs. Only at one ISP they were increasing +-2% of the decrease of the other ISPs. Spammers shift to other ISPs were they know that abuse handling is not in place or moving fast. So we do not put pressure on them. Spammers do. They put the pressure on ISPs which are not able to get their abuse handling up and running. The other big US ISP started to use our data as well and reduced his all over abuse incidents about 45% per month. > I know some abuse desks have chosen number 2 (I've helped them do it), = =20 > but I also know a number have chosen 3. That's fine. If one abuse desk is choosing number 2 things are getting better. I know about 17 abuse departments all over the world, that were starting semi automatic abuse handling till last November. And another 7 we are working together at the moment to get stuff up and running. > The abuse@ role account is not intended for high volume, automated =20 > reports. That you misuse it in that way is one of the reasons many =20 > abuse desks just ignore you. See above. > Your reputation is poor enough by this point that you might have some = > difficulty persuading an abuse desk to set up a separate alias for you = =20 > to send your high volume reports to, but it's still well worth a try. = > It will make it far more likely that the data you're attempting to =20 > communicate will be read. We will never persuade ISPs to create an alias. Because that is absolutely not what we want. What we want is an abuse@ address in the whois information. We are not accepting alias addresses. Lot's of ISPs asked if it would be possible and we didn't want to do it. Because it is not to difficult to tell the incoming mail system to move data from abusix to another folder. Filtering abusix reports to the junk folder is working as well, so where is the difference? We are getting our data from the whois information. We have worldwide 102.000 ranges. The first update run we did, brought us 88.000 abuse addresses. Today we have nearly 100.000 abuse addresses in the whois data. Little bit more than 12.000 Range Owners updated their whois information within the last 5 month, to offer an abuse address. Nice coincidence for us. About our Reputation, might be and I'm a 100% sure that there are a lot of people who do not like what we do and the way we do it. Fine. We know at least about the same amount of people that like what we do. We see huge ISPs getting their network clean, we see small ISPs sending us Easter cards and being thankful. We know about big ISPs inviting us to summits and paying for our hardware or travel costs. Sure. We will not be able to do it the right way for everybody. But we help people with what we are doing and that is a good thing. And again, not using our data and blocking us or filtering us is fine. Feel free to do so. > Once you've done that then you're in the position of being someone =20 > working alongside the abuse desk, rather than against them. As part of = =20 > the process of becoming part of the solution instead of part of the =20 > problem you'll find what formats of data the abuse desks can most =20 > easily parse. >=20 > I'd suggest you do that, and attempt to work with abuse desks, rather = > than trying to co-opt a data format as a club to use against them. As I said above, we are working closely with abuse desks all over the world. We are working with abuse desks, that want to change something. We are not working with abuse desk that are not willed to change anything or tell us in the SMTP dialog that the abuse mailbox is full. So I think, we should not argue about what is the right way or what is it not. We should try to move something. And I feel that we are doing so at the moment. So I'm happy for feedback. And I'm happy to tlak to ISPs which think we are bad bastards and explain what and why we are doing it. And I'm absolutely happy to hear suggestions critics and what so ever= =2E So feel free and tell your colleagues and customers to feel free. Thanks, and have a nice week. Tobias --=20 abusix.org --------------enig8D5546B9CE82DDD51210AB75 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpt7s8ACgkQvB4M5yQyqDecmgCbBeRSgsHA3cPKEDxW2dBhCNrE kLkAoK/ep5P2edFe+6ztTAqWR9c8OgWr =6pT4 -----END PGP SIGNATURE----- --------------enig8D5546B9CE82DDD51210AB75-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RH7msN013295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Jul 2009 10:07:54 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 12899 invoked from network); 27 Jul 2009 17:07:48 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 27 Jul 2009 17:07:48 -0000 Date: Mon, 27 Jul 2009 13:07:47 -0400 (EDT) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4A6DDBC7.8080906@knutix.de> Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> <4A6DC517.7020807@knutix.de> <4A6DDBC7.8080906@knutix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 10:07:55 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:07:55 -0000 > The ARF Draft itself could be changed. Especially part 4-d. We could > leave it like it is for email abuse and add a non email attachment for > logfiles and other contents. I see no problem with that. Don't be silly. Every current bit of software that reads ARF reports expects to find the current three parts, text, formatted text, and message. If you send something different, it doesn't matter whether you call it ARF, it won't be ARF because it won't interoperate with existing ARF software. For example, nearly all of the ARF reports I get are in fact list removal requests, so my ARF reader mostly looks at the copy of the message to get the details of who to remove from what list, and pays little attention to the formatted report part. > But if I interpret the feedback on this list right, I'm not dogmatic > enough, more pragmatic and more solution driven. I think you'll find we're quite pragmatic, but we also have a lot of experience with attempts to overload message formats, which tells us it's a bad idea. We all agree that it would be nice to have a way to report other kinds of abuse that aren't tied to a single e-mail message, but ARF isn't it. R's, John Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RH6vTe013212 for ; Mon, 27 Jul 2009 10:07:02 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id A047C8039C for ; Mon, 27 Jul 2009 10:06:40 -0700 (PDT) Message-Id: <81AD8A1A-AE5D-4AF7-BAB1-ED1B3193B1EB@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <4A6DDBE3.1090005@knutix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 10:06:56 -0700 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> <4A6DDBE3.1090005@knutix.de> X-Mailer: Apple Mail (2.935.3) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 10:07:02 -0700 (PDT) Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 17:07:02 -0000 On Jul 27, 2009, at 9:54 AM, Tobias Knecht wrote: >> Because the "M" in MAAWG stands for Messaging, and ARF is >> the format for reporting feedback about Messages. > > Sorry, but where is the "M" in ARF if it is limited to Message/Mail > Abuse? Sorry could not resist ;-) You seem to want to be taken seriously. This is the sort of behavior you should avoid if you really want that to happen. > >> Perhaps you should talk to the ISPs first, rather than just sending >> them unsolicited mail and waiting for complaints? Both IODEF >> and ARF are designed primarily for solicited reports between >> cooperating parties. If you're sending unsolicited messages, you're >> outside the main use case for either. > > Seems a little bit odd to me to ask for permission to complain about > illegal abusive behavior. The abuse@ alias is intended for individual reports. At many ISPs it's read entirely manually, with minimal automation. If you misuse it by, for example, sending 116 complaints about a single incident within a five minute period, then you're going to overwhelm the abuse desk procedures. If you do that, there are three things that the abuse desk can do. 1. The abuse desk never catches up, and becomes ineffective due to the volume. 2. The abuse desk puts some ad-hoc automation in place to extract what little data there is in the mailbomb. 3. The abuse desk puts some filtering in place to ensure that the sender of the high volume messages doesn't end up in the abuse queue. I know some abuse desks have chosen number 2 (I've helped them do it), but I also know a number have chosen 3. The abuse@ role account is not intended for high volume, automated reports. That you misuse it in that way is one of the reasons many abuse desks just ignore you. Your reputation is poor enough by this point that you might have some difficulty persuading an abuse desk to set up a separate alias for you to send your high volume reports to, but it's still well worth a try. It will make it far more likely that the data you're attempting to communicate will be read. Once you've done that then you're in the position of being someone working alongside the abuse desk, rather than against them. As part of the process of becoming part of the solution instead of part of the problem you'll find what formats of data the abuse desks can most easily parse. I'd suggest you do that, and attempt to work with abuse desks, rather than trying to co-opt a data format as a club to use against them. Cheers, Steve Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RGt1w8012359 for ; Mon, 27 Jul 2009 09:55:06 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.100]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVTTY-0002Pt-Dr; Mon, 27 Jul 2009 18:55:00 +0200 Message-ID: <4A6DDBE3.1090005@knutix.de> Date: Mon, 27 Jul 2009 18:54:59 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Steve Atkins References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> In-Reply-To: <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BFEE84AEA5F44FAC0D6D4EB" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248713706;6d0ba1fd; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 09:55:06 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:55:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BFEE84AEA5F44FAC0D6D4EB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Because the "M" in MAAWG stands for Messaging, and ARF is > the format for reporting feedback about Messages. Sorry, but where is the "M" in ARF if it is limited to Message/Mail Abuse? Sorry could not resist ;-) > Perhaps you should talk to the ISPs first, rather than just sending > them unsolicited mail and waiting for complaints? Both IODEF > and ARF are designed primarily for solicited reports between > cooperating parties. If you're sending unsolicited messages, you're > outside the main use case for either. Seems a little bit odd to me to ask for permission to complain about illegal abusive behavior. Tobias --=20 abusix.org --------------enig6BFEE84AEA5F44FAC0D6D4EB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpt2+MACgkQvB4M5yQyqDds4gCgyjMCzverYsSXIkmpKHfh3pRx 9mAAn1QXV+rXxbVR8aRK2Cz6cX1fj23R =RfwS -----END PGP SIGNATURE----- --------------enig6BFEE84AEA5F44FAC0D6D4EB-- Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RGsXeu012322 for ; Mon, 27 Jul 2009 09:54:39 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.100]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVTT6-0002PZ-NF; Mon, 27 Jul 2009 18:54:32 +0200 Message-ID: <4A6DDBC7.8080906@knutix.de> Date: Mon, 27 Jul 2009 18:54:31 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "John R. Levine" References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> <4A6DC517.7020807@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8FEE8BA7CF713B9D3784D241" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248713679;1a06a101; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 09:54:39 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:54:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FEE8BA7CF713B9D3784D241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> I fully agree that ARF is a child of RFC 3462, but I think there is no= >> line of text telling us, that there MUST be a multipart attachment >> included into the report. I am wrong? >=20 > You are wrong. Please read the relevant RFCs. Sorry I think I was not able to say exactly what I wanted to say. RFC3462: [...] The Multipart/Report content-type contains either two or three sub- parts, in the following order: 1) Would be part of any other abuse reporting as well. 2) Would be also part of any other abuse reporting. 3) Is Optional in RFC3462 [...] The ARF Draft itself could be changed. Especially part 4-d. We could leave it like it is for email abuse and add a non email attachment for logfiles and other contents. I see no problem with that. But if I interpret the feedback on this list right, I'm not dogmatic enough, more pragmatic and more solution driven. I think we should stop this discussion here. Makes no sense for us. I will talk about this discussion to BSI (German Government Security Authority). They planned to develop a complete own format for abuse reporting, I suggested to change and use ARF, my suggestions were probably wrong, so they should develop "Yet Another Abuse Reporting Format" for Germany and Europe. Nevertheless thanks for your feedback within this discussion. Tobias --=20 abusix.org --------------enig8FEE8BA7CF713B9D3784D241 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpt28cACgkQvB4M5yQyqDeCdwCfTYULy9fmp8vLg0LOvy0GQB2L Z7oAniML/8KXnLVG0n3T1u3NOy8dphVI =gCu9 -----END PGP SIGNATURE----- --------------enig8FEE8BA7CF713B9D3784D241-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RGJpmo010343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Jul 2009 09:19:57 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 59064 invoked from network); 27 Jul 2009 16:19:48 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 27 Jul 2009 16:19:48 -0000 Date: Mon, 27 Jul 2009 12:19:46 -0400 (EDT) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4A6DC517.7020807@knutix.de> Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> <4A6DC517.7020807@knutix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 09:19:57 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:19:57 -0000 > I fully agree that ARF is a child of RFC 3462, but I think there is no > line of text telling us, that there MUST be a multipart attachment > included into the report. I am wrong? You are wrong. Please read the relevant RFCs. R's, John Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RG8xtv009644 for ; Mon, 27 Jul 2009 09:09:04 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id AC31B8079F for ; Mon, 27 Jul 2009 09:08:42 -0700 (PDT) Message-Id: <57991640-44E0-4799-82E9-53B12BC23AE0@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <4A6DAAE7.1040206@knutix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 09:08:53 -0700 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> X-Mailer: Apple Mail (2.935.3) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 09:09:04 -0700 (PDT) Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:09:04 -0000 On Jul 27, 2009, at 6:25 AM, Tobias Knecht wrote: > > > They all ask for ARF, nobody asks for IODEF. Unfortunately it's not > the > first time, that not the best format is used as a standard. > > The other question is, why is everybody at MAAWG talking about ARF and > nobody talking about IODEF? Because the "M" in MAAWG stands for Messaging, and ARF is the format for reporting feedback about Messages. IODEF is not targeted at providing feedback about messages, so is of significantly less interest to typical MAAWG participants (or participants of this mailing list). > I think it's a great thing for CERTs. But is > it really the right thing for easy, high volume abuse reports? > > I would be the first person to switch to this format if I would know, > that ISPs are using it. But if we send 1.2 million reports per day > with > IODEF we will get at least 98% feedback that would tell us, not to use > this format. Perhaps you should talk to the ISPs first, rather than just sending them unsolicited mail and waiting for complaints? Both IODEF and ARF are designed primarily for solicited reports between cooperating parties. If you're sending unsolicited messages, you're outside the main use case for either. Cheers, Steve Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RFgUt0007769 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 27 Jul 2009 08:42:35 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 27 Jul 2009 08:42:30 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "abuse-feedback-report@mipassoc.org" Date: Mon, 27 Jul 2009 08:42:29 -0700 Thread-Topic: [feedback-report] IETF Standardization and ARF Version Number Thread-Index: AcoOwTm752A96USZSpWlydCuF1/7VQAD4YUw Message-ID: References: <501c18e00907270649j30b04062x311d8af622984c1e@mail.gmail.com> In-Reply-To: <501c18e00907270649j30b04062x311d8af622984c1e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 08:42:35 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n6RFgUt0007769 Subject: Re: [feedback-report] IETF Standardization and ARF Version Number X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:42:36 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Yakov Shafranovich > Sent: Monday, July 27, 2009 6:49 AM > To: abuse-feedback-report@mipassoc.org > Subject: [feedback-report] IETF Standardization and ARF Version Number > > Hello, > > Being that ARF as it is used today is pretty stable, are we ready to > move forward with formal IETF standardization? This came up today at the IETF APPS area meeting. I'm just about to query the area directors as to what they think our next steps are. > Also, on a related note, it might be prudent to change the version > number to "1.0"? I was planning to do that as part of its publication. Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RFHi9p005950 for ; Mon, 27 Jul 2009 08:17:50 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.100]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVRxQ-0004ya-2w; Mon, 27 Jul 2009 17:17:44 +0200 Message-ID: <4A6DC517.7020807@knutix.de> Date: Mon, 27 Jul 2009 17:17:43 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Yakov Shafranovich References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> In-Reply-To: <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0AAAF8FD4AE05AF449354584" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248707870;7cee407e; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 08:17:50 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:17:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0AAAF8FD4AE05AF449354584 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yakov Shafranovich schrieb: > There is a reason why ARF is widely used. When we initially got > together to create the format, one of the ongoing problems was one of > scope - people disagreed as to what information should be included, > and what not, as well as which use cases should be covered. It is > decided to specifically limit it to email related abuse. Because it > is a "child of" RFC 3462 (multipart/report), it is limited in scope to > "mail system administrative messages". Regular abuse reports of web > related abuse, hacking, etc. just don't fit. And exactly that is the problem with the format it self. On one hand it is limited and on the other hand it is not. It is limited to email related abuse and on the other hand we use it for opt-out request which is far away from real abusive behavior. We use it also for DKIM signature verification errors which is not always an abuse problem. So in my opinion ARF already mixes up several things and it would be easily possible to add other kinds of abusive behavior. I fully agree that ARF is a child of RFC 3462, but I think there is no line of text telling us, that there MUST be a multipart attachment included into the report. I am wrong? The point is, we know that ARF is used by lots of people, and we all wanna fight abusive behavior, fast. So it would be the easiest way to add other report issues into ARF and know, that lots of ISPs can benefit from that very fast. For example: We want to report a high number of phishing URI. So what would be the problem to add some highlevel values, like: * mail-abuse |-* abuse - spam or some ... |-* dkim - a DKIM ... |-* fraud - indicates ... * web-abuse |-* phishing - phishing URIs and ... |-* dictionary attacks - ... |-* ... * whatever-abuse |-* ... |-* ... For the multipart we could easily use parts of logfiles or for example full source code of phishing webpages. Or it could be decided not to require a attachment in some cases. The only thing I do not want to face again, is to tell ISPs again, to use format X and in 4 month tell them to use also format Y. And that's exactly what happens at the moment. We have the data, we have the addresses and contacts and we wanna start reporting fast, to help ISPs fa= st. > There is going to be an IETF WG for ARF soon (hopefully). One of the > things that the WG is going to discuss are use cases that MAAWG > members have put forward which are not covered in the existing spec. > Drop boxes are explicitly mentioned in the charter. I am hoping that > we can make approriate adjustments if needed, but again, they will be > limited to email/spam related abuse. See above. > Additionally, ARF and INCH were developed by different industry > segments. ARF was developed by ISPs for ISPs, designed to be > lightweight. INCH seems to originate more from CERTs and related > organizations. Now moving forward, I don't see any issue with some > sort of ARF/INCH integration - for example you can specify a related > INCH report in the ARF message. But this is really something more > suitable for the INCH/IODEF people. >=20 > Perhaps someone can make a lightweight profile of INCH, easily > transportable via email and packaged like ARF. I am not familiar > enough with it to determine if that's possible. And that way we generate another format. The problem for us is not using INCH. The problem is to force ISPs using it. And force ISPs being able to understand several formats. Question to members of ISPs here on the mailinglist. Which format is used by your abuse departments? ARF, INCH or both? Thanks, Tobias --=20 abusix.org --------------enig0AAAF8FD4AE05AF449354584 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkptxRcACgkQvB4M5yQyqDdzIQCgjFHxxGEccZHwUhgY9N/qsHB8 9McAoO91LCSrKTaAatUjODA9AGJEc4w2 =UqpG -----END PGP SIGNATURE----- --------------enig0AAAF8FD4AE05AF449354584-- Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6REfO4N003532 for ; Mon, 27 Jul 2009 07:41:30 -0700 Received: by qyk29 with SMTP id 29so3841176qyk.3 for ; Mon, 27 Jul 2009 07:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.91.133 with SMTP id n5mr3503236vcm.102.1248705683421; Mon, 27 Jul 2009 07:41:23 -0700 (PDT) In-Reply-To: <4A6DAAE7.1040206@knutix.de> References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> <4A6DAAE7.1040206@knutix.de> From: Yakov Shafranovich Date: Mon, 27 Jul 2009 10:41:03 -0400 Message-ID: <501c18e00907270741p271007b3rfea439e1416de615@mail.gmail.com> To: Tobias Knecht Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 07:41:30 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n6REfO4N003532 Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:41:30 -0000 There is a reason why ARF is widely used. When we initially got together to create the format, one of the ongoing problems was one of scope - people disagreed as to what information should be included, and what not, as well as which use cases should be covered. It is decided to specifically limit it to email related abuse. Because it is a "child of" RFC 3462 (multipart/report), it is limited in scope to "mail system administrative messages". Regular abuse reports of web related abuse, hacking, etc. just don't fit. There is going to be an IETF WG for ARF soon (hopefully). One of the things that the WG is going to discuss are use cases that MAAWG members have put forward which are not covered in the existing spec. Drop boxes are explicitly mentioned in the charter. I am hoping that we can make approriate adjustments if needed, but again, they will be limited to email/spam related abuse. Additionally, ARF and INCH were developed by different industry segments. ARF was developed by ISPs for ISPs, designed to be lightweight. INCH seems to originate more from CERTs and related organizations. Now moving forward, I don't see any issue with some sort of ARF/INCH integration - for example you can specify a related INCH report in the ARF message. But this is really something more suitable for the INCH/IODEF people. Perhaps someone can make a lightweight profile of INCH, easily transportable via email and packaged like ARF. I am not familiar enough with it to determine if that's possible. Yakov 2009/7/27 Tobias Knecht : > Hi again, > >> Hmmn.  Now that I've told you three times to look at INCH, could you >> please do so? > > I looked at it, and I knew that format before. And it is a great idea, > and I think it is the better format than ARF is. Nevertheless I feel > that it's at some points way to complicated. It is too complicated for > smaller ISPs to use it incoming and way to complicated for > users/organizations/companies to create and send. > > Which huge ISP is able to use this format today? United Internet? > Comcast? Hotmail? Deutsche Telekom? Verizon? > > They all ask for ARF, nobody asks for IODEF. Unfortunately it's not the > first time, that not the best format is used as a standard. > > The other question is, why is everybody at MAAWG talking about ARF and > nobody talking about IODEF? I think it's a great thing for CERTs. But is > it really the right thing for easy, high volume abuse reports? > > I would be the first person to switch to this format if I would know, > that ISPs are using it. But if we send 1.2 million reports per day with > IODEF we will get at least 98% feedback that would tell us, not to use > this format. > > So at the moment we are again in the sad situation, that the best format > is not used. We could use the IODEF draft and say, this is ARF 2.0 and > more people would use it, but telling ISPs to switch to or add IODEF to > their processes will not lead us to the right place. > > > Thanks, > > Tobias > > -- > abusix.org > > > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report > > Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6REPPOK002370 for ; Mon, 27 Jul 2009 07:25:30 -0700 Received: by qyk29 with SMTP id 29so3823766qyk.3 for ; Mon, 27 Jul 2009 07:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.96.66 with SMTP id g2mr3322880vcn.119.1248704723135; Mon, 27 Jul 2009 07:25:23 -0700 (PDT) From: Yakov Shafranovich Date: Mon, 27 Jul 2009 10:25:03 -0400 Message-ID: <501c18e00907270725sccd6f8ah70ec6bab78d1e6b3@mail.gmail.com> To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 07:25:31 -0700 (PDT) Subject: [feedback-report] FWD: Proposed IETF WG charter for "arf" X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:25:31 -0000 Murray Kucherawy posted this about two weeks ago to the IETF APPS list: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00798.html ----- Working Group Name: Abuse Reporting Format (ARF) IETF Area: Applications Area Chair(s): TBD Applications Area Director(s): Lisa Dusseault Alexey Melnikov Responsible Area Director: TBD Mailing Lists: General Discussion: abuse-feedback-report at mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/abuse-feedback-report Archive: http://mipassoc.org/mailman/listinfo/abuse-feedback-report Description of Working Group: Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification. ARF was developed by a messaging trade organization independent of the IETF, and uses a format similar to a Delivery Status Notification (DSN, RFC3464) to report fraud, spam, viruses or other abusive activity in the email system. The basic format is amenable to processing by humans or software, with the latter requiring the format to be standardized, to permit interoperability between automated services, particularly without prior arrangement. ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. Some tools already exist for processing ARF messages, a few of which are open source. In order to preserve the installed base, the working group will make the minimum changes necessary to the existing specification and will seek to have backward compatibility. Furthermore, some extensions to the current proposal are of interest to the community, such as the means for an operator to advertise an email address to which abuse reports using ARF should be sent. The working group will take on the task of specifying such a mechanism as part of the first draft it will issue. The initial proposal is published as draft-shafranovich-feedback-report, and this will provide the working group's starting point. In addition, the group will specify the integration of ARF into DKIM use using draft-kucherawy-dkim-reporting as its input. It contains extensions to DKIM that are related to ARF as a means of reporting DKIM-related failures which include phishing ("fraud") and as such are relevant to the ARF effort. Goals and Milestones: Sep 09 Issue first WG-based Internet-Draft defining ARF Nov 09 Achieve consensus on any WG-based changes to ARF Dec 09 Submit ARF ID to IESG for publication Feb 10 Issue first WG-based ID about DKIM reporting extensions May 10 Achieve consensus on DKIM reporting extensions draft Jun 10 Submit DKIM reporting ID to IESG for publication Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RDnN9n032422 for ; Mon, 27 Jul 2009 06:49:28 -0700 Received: by qyk29 with SMTP id 29so3788767qyk.3 for ; Mon, 27 Jul 2009 06:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.96.66 with SMTP id g2mr3257219vcn.119.1248702562198; Mon, 27 Jul 2009 06:49:22 -0700 (PDT) From: Yakov Shafranovich Date: Mon, 27 Jul 2009 09:49:02 -0400 Message-ID: <501c18e00907270649j30b04062x311d8af622984c1e@mail.gmail.com> To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 06:49:28 -0700 (PDT) Subject: [feedback-report] IETF Standardization and ARF Version Number X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 13:49:28 -0000 Hello, Being that ARF as it is used today is pretty stable, are we ready to move forward with formal IETF standardization? Also, on a related note, it might be prudent to change the version number to "1.0"? Yakov Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6RDQ4M9030410 for ; Mon, 27 Jul 2009 06:26:10 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.100]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVQDL-0006eB-5x; Mon, 27 Jul 2009 15:26:03 +0200 Message-ID: <4A6DAAE7.1040206@knutix.de> Date: Mon, 27 Jul 2009 15:25:59 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "John R. Levine" References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC09A348184AE1FF90F2C32DC" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248701170;c939c36b; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 27 Jul 2009 06:26:10 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 13:26:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC09A348184AE1FF90F2C32DC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, > Hmmn. Now that I've told you three times to look at INCH, could you > please do so? I looked at it, and I knew that format before. And it is a great idea, and I think it is the better format than ARF is. Nevertheless I feel that it's at some points way to complicated. It is too complicated for smaller ISPs to use it incoming and way to complicated for users/organizations/companies to create and send. Which huge ISP is able to use this format today? United Internet? Comcast? Hotmail? Deutsche Telekom? Verizon? They all ask for ARF, nobody asks for IODEF. Unfortunately it's not the first time, that not the best format is used as a standard. The other question is, why is everybody at MAAWG talking about ARF and nobody talking about IODEF? I think it's a great thing for CERTs. But is it really the right thing for easy, high volume abuse reports? I would be the first person to switch to this format if I would know, that ISPs are using it. But if we send 1.2 million reports per day with IODEF we will get at least 98% feedback that would tell us, not to use this format. So at the moment we are again in the sad situation, that the best format is not used. We could use the IODEF draft and say, this is ARF 2.0 and more people would use it, but telling ISPs to switch to or add IODEF to their processes will not lead us to the right place. Thanks, Tobias --=20 abusix.org --------------enigC09A348184AE1FF90F2C32DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkptqukACgkQvB4M5yQyqDewDwCeOECtmNt0V3IBdPFw8mdTobUe c4sAnArTKj7G4bwbMgD9fpHGGiS2ybn1 =MJ56 -----END PGP SIGNATURE----- --------------enigC09A348184AE1FF90F2C32DC-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QMdrkN005200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Jul 2009 15:39:59 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 18330 invoked from network); 26 Jul 2009 22:39:53 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 26 Jul 2009 22:39:53 -0000 Date: Sun, 26 Jul 2009 18:39:53 -0400 (EDT) From: "John R. Levine" To: Richard Conner In-Reply-To: Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 15:39:59 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 22:40:00 -0000 > What I gather from the previous discussions is that ARF is intended to > handle mainly cases like #1 above. No, it's useful for reporting a single e-mail message, regardless of what it contains. I suppose you might send reports to multiple places for dropboxes, funky URLs, or whatever. The question is still open whether you'd make a combo report of everything you don't like about the message and send it to all of the responsible parties, or you'd send different reports pointing out the individual bits that each reportee is supposed to deal with. R's, John PS: > Also, as always, it seems that the outcome of an abuse report will > depend at least as much upon the responsiveness of the report > recipient than the form in which the report is sent Of course. Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QLgk6D002141 for ; Sun, 26 Jul 2009 14:42:52 -0700 Received: from [10.0.1.2] ([70.21.9.250]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNE0012SPIV89A6@vms173001.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Sun, 26 Jul 2009 15:42:31 -0500 (CDT) Message-id: From: Richard Conner To: ARF mailing list In-reply-to: Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Sun, 26 Jul 2009 16:42:31 -0400 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 01:00:11 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 14:42:52 -0700 (PDT) Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 21:42:52 -0000 On Jul 26, 2009, at 3:00 PM, John R. Levine wrote: > There's been a lot of work on "Incident Handling", where an incident > consists of multiple events. To some of us, a single abusive e-mail message can be an "incident" all by itself according to this definition, because of the multiplicity of ruses and dodges used by the sender. For example, I have a message in my inbox today that has the following taints of network abuse all over it: 1. Message sent to my provider's MX from a dynamic pool host with a forged HELO, so probably a botnet mailing. Probably some federal law violations there, in any case it is theft of service from the provider and from the bot's owner (not to mention malicious vandalism to the bot computer). 2. Message contains a URL whose host resolves simultaneously to 10 or more IP addresses in widely differing blocks, each with TTL on the order of a couple of minutes. Again, more botnet activity (fast flux), both for public HTTP service and for authoritative DNS (which is also hosted on some of these same addresses). More theft of service, more possible violations of the law. 3. Using domain-WHOIS to look into the domain in the URL, I find that the registrant data is incomplete and demonstrably inaccurate. This is a violation of ICANN policy regarding the accuracy and reliability of registrant info. 4. The domain of the authNS for the URL is different, and has its own hosting rotation and forged registrant info. More theft, more crime, yadda yadda ... What I gather from the previous discussions is that ARF is intended to handle mainly cases like #1 above. If it is useful for these, then I take my hat off to it. However, I personally have ways to report message sources that are far easier for me to use as an end-user of e- mail. ARF seems not to be so useful for pointing out peripheral technical problems (like drop boxes) related to mail abuse. Also, as always, it seems that the outcome of an abuse report will depend at least as much upon the responsiveness of the report recipient than the form in which the report is sent (assuming, of course, that the report's details are accurate and pertinent). Good providers will act even on humble plain-text reports like mine, other providers, well ... -- rick Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QLELJP000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Jul 2009 14:14:27 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 46214 invoked from network); 26 Jul 2009 21:14:21 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 26 Jul 2009 21:14:21 -0000 Date: Sun, 26 Jul 2009 22:14:20 +0100 (BST) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4A6CC66F.40902@knutix.de> Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC66F.40902@knutix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 14:14:27 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 21:14:27 -0000 > built up a Abuse Contact Database. More information on that: > > http://www.abusix.de/abuse-contact-db/ Sounds swell. At some point we should integrate it with abuse.net. > What we need is a format that is already used by ISPs and that is able > to handle not only email incidents. Hmmn. Now that I've told you three times to look at INCH, could you please do so? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QLBCNv000540 for ; Sun, 26 Jul 2009 14:11:17 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.106]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVAzv-0006m5-IR; Sun, 26 Jul 2009 23:11:11 +0200 Message-ID: <4A6CC66F.40902@knutix.de> Date: Sun, 26 Jul 2009 23:11:11 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "John R. Levine" References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9FE9286406F8DCD87AE1DC1F" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248642677;ebfdf204; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 14:11:17 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 21:11:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9FE9286406F8DCD87AE1DC1F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again ;-) okay I want just tell you a second which way we (abusix.org) thinks is a way to get internet abuse under control. We believe the only way to stop internet abuse is at its source. And the only group of people who could stop the abusive behavior are the abuse departments and system administrator in the world. Biggest problem today is, that most of the ISPs do not really see what's going on in their network. Therefor we started the so called Global Reporting Project. That means we report at the moment about 1.2 million spam trap hits to ISP abuse desks. Some of them handling them, some don't. But now they can see whats going on in their networks and stop it, if they are willed to. We know, that we can not force ISPs to handle their abuse. BUT, what we have seen since last yer is very interesting. Huge US dial-up ISP started to use our data and locked customers after the 3rd complaint from us. Within 2 month the hourly report rate decreased from ~600 to ~60 reports. They told me, since they are locking down customers immediately the number of incidents was reduced about 45% per month. That means spammers move to more spammer friendly networks, 'cause they do not pay money for a bot network that is closed within minutes. ISPs who are not doing abuse handling will get under pressure in future. Cause spammers will more and more use their networks. We have seen that already with some other ISPs. At the moment we are fighting at different places to get abuse reporting and handling problems solved. 1.) Abuse contacts. At some RIRs it's a mess to get the right abuse contacts to report spamtrap hits for example automatically. Therefor we built up a Abuse Contact Database. More information on that: http://www.abusix.de/abuse-contact-db/ 2.) It makes no sense to have 15 different email addresses for 15 different kinds of abusive behavior. There must be one way to handle it. That problem leads us to the 3rd problem. 3.) If there would be ony format, that is able to adopt every kind of abusive behavior, it would be absolutely easy for reporters to handle everything with one script/format/whatever ... On the other hand it would be absolutely easy for ISPs to route the complaints to the right place, if there is more than one place. What we need is a format that is already used by ISPs and that is able to handle not only email incidents. For example, we are working with surbl and would like to start a global reporting service with data from the surbl list. That means we use the surbl list and report all URIs that are on that list to the responsible IP address owner of the A-Record and recommend to shutdown that site. How could we do that today with ARF? I think there is no way so far. I hope I was able to show it in an appropriate way what we are doing. So feel free to tell us your opinion about that. And give us suggestions on how we could handle that. Thanks, Tobias --=20 abusix.org John R. Levine schrieb: >>>> Reporting Format" but at the moment it's not possible to report all >>>> kinds of abuse with it. Dropboxes, Phishing, DoS, ... >=20 > We designed ARF for a limited purpose: reports about a single e-mail=20 > message. It serves that purpose pretty well, give or take possible=20 > niggles about extra details one might want to point out in the message.= >=20 > There's been a lot of work on "Incident Handling", where an incident=20 > consists of multiple events. The IETF INCH group produced RFC 5070 whi= ch=20 > defines the Incident Object Description Exchange Format (IODEF), a rath= er=20 > complex XML format, along with some other documents still in draft form= =20 > including an implemenation guide, how you pass them via SOAP, and some = > other stuff. It's always surprised me that this activity seems to be=20 > going on with no input from the anti-spam community. >=20 > Take a look here to see current activities: >=20 > http://www.cert.org/ietf/inch/inch.html >=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for D= ummies", > Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-May= or > "More Wiener schnitzel, please", said Tom, revealingly. > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report >=20 --------------enig9FE9286406F8DCD87AE1DC1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpsxm8ACgkQvB4M5yQyqDdLxwCfUzvTLY4kj+6/WIABvmWYiViG rjkAoIcRe5EZAY4Sf8CzvPil4Ej4VPFy =NSK/ -----END PGP SIGNATURE----- --------------enig9FE9286406F8DCD87AE1DC1F-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QL8qwY000379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Jul 2009 14:08:58 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 41958 invoked from network); 26 Jul 2009 21:08:50 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 26 Jul 2009 21:08:50 -0000 Date: Sun, 26 Jul 2009 22:08:50 +0100 (BST) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4A6CC114.1000501@knutix.de> Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> <4A6CC114.1000501@knutix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 14:08:59 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 21:08:59 -0000 > Phishing emails yes. But no information from different sources. You really need to look at the INCH work. It seems to be well respected by CERTs, and there is no advantage to reinventing this wheel. R's, John Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QKmcXO031702 for ; Sun, 26 Jul 2009 13:48:43 -0700 Received: from [10.0.1.2] ([70.21.19.46]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNE001GBN0SBSTC@vms173007.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Sun, 26 Jul 2009 14:48:28 -0500 (CDT) Message-id: <3AC11130-45F8-477E-A53D-BE4A9BFB56A6@bellatlantic.net> From: Richard Conner To: abuse-feedback-report@mipassoc.org In-reply-to: Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Sun, 26 Jul 2009 15:48:28 -0400 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 01:00:05 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 13:48:43 -0700 (PDT) Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 20:48:43 -0000 On Jul 26, 2009, at 12:26 PM, Murray S. Kucherawy wrote: > So, do you have proposed text changes to the draft that cover these > cases? Or can someone make such a proposal? I hadn't phrased it as a text change, but I did suggest a feedback type on the order of "fraud drop-box". It was also pointed out to me that I could report a mailto: URI, which would probably be close enough to what I would want to use, and would not require a text change. This whole affair was occasioned by Hotmail rejecting one of my reports on a 419 drop box in their domain. They indicated that they preferred to see reports in ARF format, so I had a look to see if ARF would improve the effectiveness of my personal reporting. So far as I can determine, it would not. For this reason, I'm not going to adopt it, and I won't burden the folks here with any sort of proposed changes. > > Also, doesn't ARF already cover phishing, as "fraud"? As far as I can see, yes it does, but it does not point very well to the specific network problem that the reporter wants to see investigated. I wanted a way to make it very clear to the report recipient that I was reporting a drop box, and not any other sort of issue. I did not want to give the recipient an easy means to disregard my report by misconstruing it. Many providers (mercifully not all of them) will discard any "fraud" report (in any format, perhaps) if the message headers do not show that the message came from their domain; they turn a blind eye to the fact that the crook may be using demonstrably-valid and unspoofed e- mail addresses that they issued. An extremist would make the claim that these providers, once having been notified of this activity, then become post-facto accessories. I also have learned that when such dropboxes are reported internally by Hotmail users (as opposed to outsiders like me), they get investigated and closed. I hardly know what to make of such behavior. I would make the pedantic distinction between phishing (the crook pretends to be your bank and is after your ID info) and advance-fee or 419 scams (the crook pretends to be Idi Amin's nephew and is after your cash). The reason for the distinction is that scammers in the latter case very commonly use freemail drop boxes, and it seems to me that these ought to be closed up wherever it can be proved that they are being used for such criminal activity. And, yes, there are protocols you can follow to minimize the chance that you would be reporting a spoofed address; I have enumerated the ones I follow in earlier posts. -- rick Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QKmL3i031681 for ; Sun, 26 Jul 2009 13:48:27 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.106]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVAdo-0005PV-Su; Sun, 26 Jul 2009 22:48:20 +0200 Message-ID: <4A6CC114.1000501@knutix.de> Date: Sun, 26 Jul 2009 22:48:20 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Steve Atkins References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig235058E4475DBC45FC15FA2A" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248641307;4a4385fc; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 13:48:27 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 20:48:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig235058E4475DBC45FC15FA2A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, short answer, long mail later ;-) >>> In our opinion ARF itself has one big problem and it's kind of the >>> problem Richard Connor is talking about. ARF is called the "Abuse >>> Reporting Format" but at the moment it's not possible to report all >>> kinds of abuse with it. Dropboxes, Phishing, DoS, ... >> I'm happy to have that discussion take place here. This isn't the =20 >> first time I've heard of all of those as possible ARF extensions, =20 >> and really given the standards activity around it, now's the time to = >> have those conversations. >> >> So, do you have proposed text changes to the draft that cover these =20 >> cases? Or can someone make such a proposal? >=20 > I think that the email related ones are already covered. Dropbox =3D=3D= =20 > Reported-URI:mailto:. Phishing =3D=3D Feedback-Type:fraud. Right. But we also have phishing data, that is not mail related. > ARF is not an appropriate format, really, for DoS as it's intended to = > encapsulate a reported message (typically email, but somewhat =20 > extensible to other messaging systems, I'd guess). I think a little bit different. We have seen a really big effort by only reporting spam messages to the ISPs. Lots of huge ISPs already use our data and lock customers very very fast. Some do that within seconds, 'cause they trust our data. If an attacked ISP could be able to reports information about bad behaving IP addresses to the network owner, they would be able to lock customers very fast. That way DoS attack would stop earlier or loose power faster than they do at the moment. I know, that this is not working perfectly at the moment, 'cause lot's of ISPs do not care about abuse handling, but I bet they will one time. The more ISPs handle their abuse faster the better this works. > There are other standards for reporting packet or log based issues, I = > believe (IDMEF aka RFC 4765 might be one. There are others, I think.). Unfortunately not always the best standard is adopted by the mass. I think we have seen that several times. ARF is in my opinion the most used reporting format, and to be honest, it's hard enough to force ISPs getting their abuse handling up and running, and it is hard to get them to ARF. It's not the right way to offer them 5 different formats. >> Also, doesn't ARF already cover phishing, as "fraud"? Phishing emails yes. But no information from different sources. Tobias --=20 abusix.org --------------enig235058E4475DBC45FC15FA2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpswRQACgkQvB4M5yQyqDfuOgCfdJ0fqGktGoe0x4s5g0F6+gt3 F8gAoILFk0B4xeGh50R3XExvqL5Ed6u/ =m3Dm -----END PGP SIGNATURE----- --------------enig235058E4475DBC45FC15FA2A-- Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QKcJux031112 for ; Sun, 26 Jul 2009 13:38:24 -0700 Received: from p5b336c55.dip.t-dialin.net ([91.51.108.85] helo=[192.168.1.106]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MVAU3-0004mn-HX; Sun, 26 Jul 2009 22:38:15 +0200 Message-ID: <4A6CBEB7.1040309@knutix.de> Date: Sun, 26 Jul 2009 22:38:15 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig98A48C91D878F2CA0F04D9DA" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248640704;88de898d; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 13:38:25 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 20:38:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig98A48C91D878F2CA0F04D9DA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, short answers to the mail. Big mail will follow later. ;-) >> In our opinion ARF itself has one big problem and it's kind of the >> problem Richard Connor is talking about. ARF is called the "Abuse >> Reporting Format" but at the moment it's not possible to report all >> kinds of abuse with it. Dropboxes, Phishing, DoS, ... >=20 > I'm happy to have that discussion take place here. This isn't the firs= t time I've heard of all of those as possible ARF extensions, and really = given the standards activity around it, now's the time to have those conv= ersations. Okay lets start now. ;-) > So, do you have proposed text changes to the draft that cover these cas= es? Or can someone make such a proposal? I have some handwritten stuff here and a proposal of the BSI Germany, which includes lots of stuff that in my opinion is not fitting in the general idea of ARF. I will try to get that stuff together within this week. > Also, doesn't ARF already cover phishing, as "fraud"? Right but only on mail base. More in my big, huge mail later. Tobias --=20 abusix.org --------------enig98A48C91D878F2CA0F04D9DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpsvrcACgkQvB4M5yQyqDePOQCgx+UOEUn9gy8OgvXKuDQnAHjb 2isAoLYlVt0vnl5EA3SFUAWNnJpowFLY =NbJL -----END PGP SIGNATURE----- --------------enig98A48C91D878F2CA0F04D9DA-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QJ0WFp025215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Jul 2009 12:00:38 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 34961 invoked from network); 26 Jul 2009 19:00:32 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 26 Jul 2009 19:00:32 -0000 Date: Sun, 26 Jul 2009 20:00:31 +0100 (BST) From: "John R. Levine" To: ARF mailing list In-Reply-To: Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 12:00:39 -0700 (PDT) Subject: [feedback-report] The limits of ARF, and INCH X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 19:00:39 -0000 >>> Reporting Format" but at the moment it's not possible to report all >>> kinds of abuse with it. Dropboxes, Phishing, DoS, ... We designed ARF for a limited purpose: reports about a single e-mail message. It serves that purpose pretty well, give or take possible niggles about extra details one might want to point out in the message. There's been a lot of work on "Incident Handling", where an incident consists of multiple events. The IETF INCH group produced RFC 5070 which defines the Incident Object Description Exchange Format (IODEF), a rather complex XML format, along with some other documents still in draft form including an implemenation guide, how you pass them via SOAP, and some other stuff. It's always surprised me that this activity seems to be going on with no input from the anti-spam community. Take a look here to see current activities: http://www.cert.org/ietf/inch/inch.html Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QHUTtP019401 for ; Sun, 26 Jul 2009 10:30:34 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 69AD08089B for ; Sun, 26 Jul 2009 10:30:10 -0700 (PDT) Message-Id: From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 26 Jul 2009 10:30:19 -0700 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> X-Mailer: Apple Mail (2.935.3) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 10:30:34 -0700 (PDT) Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 17:30:34 -0000 On Jul 26, 2009, at 9:26 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- >> feedback-report-bounces@mipassoc.org] On Behalf Of Tobias Knecht >> Sent: Saturday, July 25, 2009 3:06 AM >> To: John R. Levine >> Cc: abuse-feedback-report@mipassoc.org >> Subject: Re: [feedback-report] Feedback types & e-mail drop boxes >> >> [...] >> In our opinion ARF itself has one big problem and it's kind of the >> problem Richard Connor is talking about. ARF is called the "Abuse >> Reporting Format" but at the moment it's not possible to report all >> kinds of abuse with it. Dropboxes, Phishing, DoS, ... > > I'm happy to have that discussion take place here. This isn't the > first time I've heard of all of those as possible ARF extensions, > and really given the standards activity around it, now's the time to > have those conversations. > > So, do you have proposed text changes to the draft that cover these > cases? Or can someone make such a proposal? I think that the email related ones are already covered. Dropbox == Reported-URI:mailto:. Phishing == Feedback-Type:fraud. ARF is not an appropriate format, really, for DoS as it's intended to encapsulate a reported message (typically email, but somewhat extensible to other messaging systems, I'd guess). There are other standards for reporting packet or log based issues, I believe (IDMEF aka RFC 4765 might be one. There are others, I think.). > > Also, doesn't ARF already cover phishing, as "fraud"? Yup. Cheers, Steve Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QGvO6U017145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Sun, 26 Jul 2009 09:57:29 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Sun, 26 Jul 2009 09:26:48 -0700 From: "Murray S. Kucherawy" To: Tobias Knecht , "John R. Levine" Date: Sun, 26 Jul 2009 09:26:45 -0700 Thread-Topic: [feedback-report] Feedback types & e-mail drop boxes Thread-Index: AcoNFM9H5C1VU5v1TJGu1tgmhpnHnwA+NORA Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <4A6AD8FB.5060109@knutix.de> In-Reply-To: <4A6AD8FB.5060109@knutix.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Greylist: Delayed for 00:30:33 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 26 Jul 2009 09:57:29 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n6QGvO6U017145 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 16:57:30 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Tobias Knecht > Sent: Saturday, July 25, 2009 3:06 AM > To: John R. Levine > Cc: abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] Feedback types & e-mail drop boxes > > [...] > In our opinion ARF itself has one big problem and it's kind of the > problem Richard Connor is talking about. ARF is called the "Abuse > Reporting Format" but at the moment it's not possible to report all > kinds of abuse with it. Dropboxes, Phishing, DoS, ... I'm happy to have that discussion take place here. This isn't the first time I've heard of all of those as possible ARF extensions, and really given the standards activity around it, now's the time to have those conversations. So, do you have proposed text changes to the draft that cover these cases? Or can someone make such a proposal? Also, doesn't ARF already cover phishing, as "fraud"? Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6PAfcUg004795 for ; Sat, 25 Jul 2009 03:41:43 -0700 Received: from p5b336b32.dip.t-dialin.net ([91.51.107.50] helo=[192.168.1.100]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MUe8V-0004yM-K5; Sat, 25 Jul 2009 12:05:51 +0200 Message-ID: <4A6AD8FB.5060109@knutix.de> Date: Sat, 25 Jul 2009 12:05:47 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "John R. Levine" References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F2812034677EFDB74086E4C" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1248518503;f1573d33; X-Greylist: Delayed for 00:35:45 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 25 Jul 2009 03:41:43 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 10:41:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F2812034677EFDB74086E4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John R. Levine schrieb: >> There are people who send unsolicited reports to abuse@ in ARF >> format, but those reports are not treated in any way differently to >> any other email sent to abuse@. If the ticketing system being used >> to handle abuse@ doesn't handle MIME well, then the report >> in ARF format is far less use than one sent as plain text, and may >> well be ignored. This isn't ideal, but that's just how some abuse >> desk infrastructure is built. >=20 > FYI, I've been sending reports to abuse desks (or whatever addresses I = can=20 > pick up from abuse.net) and it works surprisingly well. Now and then I= =20 > get "the message didn't have full headers" because their ticketing syst= em=20 > or their MUA smashed the message, but for the most part I get responses= at=20 > least as good as I got with plain text. That's exactly what we (abusix.org) see every day. When we switched reporting format from plain/text to ARF we got several emails from huge ISPs telling us, thank you for using ARF and we got lots of emails from ISPs asking us to use plain/text again. We said, ARF is the standard and they should adopt ARF into their systems. And they did. I know about nearly 50 ISPs in the world which were not able to handle ARF last November and are able today. I think that is a pretty good rate. In our opinion ARF itself has one big problem and it's kind of the problem Richard Connor is talking about. ARF is called the "Abuse Reporting Format" but at the moment it's not possible to report all kinds of abuse with it. Dropboxes, Phishing, DoS, ... Lots of ISPs tell us, that it would make things much more easy to have one format send to one address and route their stuff in house to the right place. I have been working for a huge abuse desk in Europe for a while and in environments like that, it is absolutely impossible to handle every single report as long as it is not aggregated, allocated, =2E.. automatically. We believe and we already saw it, that ARF would be much more powerful if there would be the possibility to reports every kind of abusive behavior and on the other side having the right contact to send stuff. That's what we are working on at abusix.org and I'm happy that this discussion came up now, 'cause within the next 3 month I would have started it myself. Thank Richard ;-) Tobias --=20 abusix.org --------------enig0F2812034677EFDB74086E4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpq2P8ACgkQvB4M5yQyqDdh4wCfQROOCUCp8UCg0l55sIGhm64x KosAoOu8jV7OltRNRoDu25Y0kr8to1Mg =uC1V -----END PGP SIGNATURE----- --------------enig0F2812034677EFDB74086E4C-- Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6ONSFhO032686 for ; Fri, 24 Jul 2009 16:28:21 -0700 Received: from [10.0.1.2] ([70.21.17.191]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNB00LFR52MRR66@vms173009.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Fri, 24 Jul 2009 17:27:58 -0500 (CDT) Message-id: <0A3F27E7-5207-456E-B928-2876E4EF8C74@bellatlantic.net> From: Richard Conner To: abuse-feedback-report@mipassoc.org In-reply-to: <501c18e00907240645rf745b96p96cc41a33c45367a@mail.gmail.com> Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Fri, 24 Jul 2009 18:27:58 -0400 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <501c18e00907240645rf745b96p96cc41a33c45367a@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 01:00:07 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 16:28:21 -0700 (PDT) Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 23:28:21 -0000 On Jul 24, 2009, at 9:45 AM, Yakov Shafranovich wrote: > Furthermore, simply having a different "Reply To" might just be a joe > job - often spammers will include a different email within the body > itself. From the provider's viewpoint it is hard to confirm that the > address in question is part of a scam without examining emails in > their mailbox which may have legal and privacy implications. Generally, when I receive such mails, I check the body first for an address -- if there's one there then I will LART it. Failing that, I move on to look for a distinct Reply-To. I'm less likely to report a From address, particularly if the freemail provider is already getting dinged for being the mail source. I agree that the provider has a hard time proving the scamminess of an address on the basis of one or two complaints, but I think the proof would become far, far easier if they received many reports of the same issue from different people. As far as e-mail privacy goes, there are limits there as with everything else. The USPS postal inspector can open your mail with the proper authorization, and the cops can likewise tap your phone with the correct warrants. I hear wild rumors that some of these drop-boxes are left open on purpose so that law enforcement can "tap" them to collect evidence. Don't know whether this is true, but it is why I don't get upset if I don't get a positive response from these complaints. On the other hand, getting negative responses from the provider (i.e., "pound sand, it didn't come from here) is unacceptable to me. > I routinely get irate replies from people who seem to think that spam > they received comes from when a spammer is simply using one of my > domains as their from/sender/reply to addresses. Been there, done that, got the souvenir USB drive. Likewise with receiving delay-bounces to hundreds or thousands of messages I didn't send. There are still many mail operators who do not observe the recommendations of SMTP (particularly the new version from last year) regarding delay-bouncing (and suppression thereof). This happens to me about 2x per year. I put together a small web page that I offer to folks who are plagued with this problem, they can cite it in replies: http://www.rickconner.net/spamweb/notmyaddress.html > I would recommend in addition to what John said below, to include a > detailed explanation in the first part of the ARF report that is meant > for humans so the abuse desk (if they read it), will at least > understand what you are trying to report. Pretty much this is already what I do. I will point out specifically that I am reporting a Reply-To address, and request that incoming mail to the address be stopped. I do not allege that the mailing came from their IP space (unless of course it did). It was just such a message that elicited the response I quoted in my earlier reply. -- rick Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OMpa00031386 for ; Fri, 24 Jul 2009 15:51:42 -0700 Received: from [10.0.1.2] ([70.21.17.191]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNB009F53C730U3@vms173015.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Fri, 24 Jul 2009 16:50:31 -0500 (CDT) Message-id: From: Richard Conner To: "Matthew Vernhout" In-reply-to: <83005F77C514DA41B067EB6FFF7E715D1DEE93B7@TOR2.corp.thindata.net> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Fri, 24 Jul 2009 17:50:31 -0400 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> <83005F77C514DA41B067EB6FFF7E715D1DEE93B7@TOR2.corp.thindata.net> X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 01:00:37 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 15:51:42 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 22:51:42 -0000 On Jul 24, 2009, at 9:21 AM, Matthew Vernhout wrote: > Richard do you mind if I forward your note to the Anti-Phishing group > within MAAWG? Not at all. Anything to raise some awareness. -- rick Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OMlQan031275 for ; Fri, 24 Jul 2009 15:47:32 -0700 Received: from [10.0.1.2] ([70.21.17.191]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNB002RP35DUZV0@vms173003.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Fri, 24 Jul 2009 16:46:26 -0500 (CDT) Message-id: <4EC4D6CA-D3B4-4CD0-B9FF-0EF33B11AF74@bellatlantic.net> From: Richard Conner To: abuse-feedback-report@mipassoc.org In-reply-to: Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Fri, 24 Jul 2009 17:46:25 -0400 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 01:00:28 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 15:47:32 -0700 (PDT) Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 22:47:32 -0000 On Jul 24, 2009, at 5:05 AM, John Levine wrote: > Indeed, but this is a policy rather than a technical issue. ARF > already lets you do this: > > Reported-Domain: hotmail.com > Reported-URI: mailto:dropbox@hotmail.com Thanks, this is close enough to what I was thinking. > But so long as Hotmail's abuse department only has scripts that say > "not from us", it doesn't matter what we send them. > The smart ones scan the reported message for their own domains and > IP ranges. The less smart ones just have people with scripts. I'm > sure we've all had script readers write back "not from us" even when > the spam is from their own MTAs on their own IPs with their own > unforged addresses in the headers. Indeed. -- rick Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OMUgv8030610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jul 2009 15:30:48 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 87023 invoked from network); 24 Jul 2009 22:30:42 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Jul 2009 22:30:42 -0000 Date: Fri, 24 Jul 2009 23:30:42 +0100 (BST) From: "John R. Levine" To: Richard Conner In-Reply-To: Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 15:30:48 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 22:30:49 -0000 > reply seems even odder to me. If we read between the lines, this might > really say "send us the message in ARF so we can ignore it more > efficiently." That would be consistent with my experience. R's, John Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OMNSWi030181 for ; Fri, 24 Jul 2009 15:23:33 -0700 Received: from [10.0.1.2] ([70.21.17.191]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNB00KHH4UVKIA8@vms173011.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Fri, 24 Jul 2009 17:23:19 -0500 (CDT) Message-id: From: Richard Conner To: abuse-feedback-report@mipassoc.org In-reply-to: Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Fri, 24 Jul 2009 18:23:19 -0400 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> X-Mailer: Apple Mail (2.935.3) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 15:23:34 -0700 (PDT) Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 22:23:34 -0000 On Jul 24, 2009, at 10:10 AM, Steve Atkins wrote: > Unless you have an agreed relationship with the ISP you're sending > the report to, ARF is probably not the best format to use. Instead > send plain text, with the message inline and a brief (5 line or less) > intro telling them what the drop box is and why. The latter is what I have generally been doing, however the reply I got from Hotmail made me wonder whether a change in tactics would be useful. Here's the text of the relevant portion of the reply: "Windows Live Hotmail processes complaints received in the Abuse Reporting Format (ARF) format. ARF is the industry standard for reporting spam complaints. Using the ARF format helps us ensure that someone can only report complaints about mail actually generated by a Windows Live Hotmail user. A valid ARF formatted complaint is a message containing the entire original spam or abusive message (including all message headers) as an attachment. To learn more about ARF, review the draft RFC at: http://www.mipassoc.org/arf/specs/draft-shafranovich-feedback-report-05.txt ." Now knowing at least a bit more about ARF than I did 24 hrs ago, this reply seems even odder to me. If we read between the lines, this might really say "send us the message in ARF so we can ignore it more efficiently." You guys will also note that they gave a link to a version of the RFC that is at least two versions (and several months) out of date, this was a problem before I dug around a bit deeper on the ARF website. > There are people who send unsolicited reports to abuse@ in ARF > format, but those reports are not treated in any way differently to > any other email sent to abuse@. If the ticketing system being used > to handle abuse@ doesn't handle MIME well, then the report > in ARF format is far less use than one sent as plain text, and may > well be ignored. This isn't ideal, but that's just how some abuse > desk infrastructure is built. Given the relative difficulty of pulling together the code needed to create ARF messages, then, perhaps I'm better off sticking with plain text. -- rick Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OMEZCG029760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jul 2009 15:14:41 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 73290 invoked from network); 24 Jul 2009 22:14:35 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Jul 2009 22:14:35 -0000 Date: Fri, 24 Jul 2009 23:14:19 +0100 (BST) From: "John R. Levine" To: Steve Atkins In-Reply-To: Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ReSent-Date: Fri, 24 Jul 2009 23:14:33 +0100 (BST) ReSent-From: "John R. Levine" ReSent-To: ARF mailing list ReSent-Subject: Re: [feedback-report] Feedback types & e-mail drop boxes ReSent-Message-ID: ReSent-User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 15:14:42 -0700 (PDT) Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 22:14:42 -0000 > There are people who send unsolicited reports to abuse@ in ARF > format, but those reports are not treated in any way differently to > any other email sent to abuse@. If the ticketing system being used > to handle abuse@ doesn't handle MIME well, then the report > in ARF format is far less use than one sent as plain text, and may > well be ignored. This isn't ideal, but that's just how some abuse > desk infrastructure is built. FYI, I've been sending reports to abuse desks (or whatever addresses I can pick up from abuse.net) and it works surprisingly well. Now and then I get "the message didn't have full headers" because their ticketing system or their MUA smashed the message, but for the most part I get responses at least as good as I got with plain text. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from fich.unl.edu.ar (fich.unl.edu.ar [168.96.132.90]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OJvk6G024020 for ; Fri, 24 Jul 2009 12:57:52 -0700 X-Spam-Status: No, hits=2.8 required=4.7 tests=AWL: 0.419,BAYES_00: -1.665,FORGED_MUA_OUTLOOK: 4.056, TOTAL_SCORE: 2.810 X-Spam-Level: ** Received: from Javier2 ([201.231.13.115]) (authenticated user rjgodoy@fich.unl.edu.ar) by fich.unl.edu.ar (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits)); Fri, 24 Jul 2009 16:27:42 -0300 Message-ID: <396C53ECA24146B5A583355A284A3F46@Javier2> From: "Javier Godoy" To: "Steve Atkins" References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> Date: Fri, 24 Jul 2009 15:57:01 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Greylist: Delayed for 00:30:06 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 12:57:52 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 19:57:53 -0000 On 2009-07-24T11:10, Steve Atkins wrote: > Abuse desks typically don't read ARF reports at all. That's sort of > the point, as they're intended to be machine-readable and processed > mechanically. > > Unless you have an agreed relationship with the ISP you're sending > the report to, ARF is probably not the best format to use. Instead > send plain text, with the message inline and a brief (5 line or less) > intro telling them what the drop box is and why. > > There are people who send unsolicited reports to abuse@ in ARF > format, but those reports are not treated in any way differently to > any other email sent to abuse@. If the ticketing system being used > to handle abuse@ doesn't handle MIME well, then the report > in ARF format is far less use than one sent as plain text, and may > well be ignored. This isn't ideal, but that's just how some abuse > desk infrastructure is built. I do not agree. In my experience (+1500 reports sent as an end-user) abuse desks which ignore ARF, usually also ignores text/plain. So far, nobody complained about the format. If with "doesn't handle MIME well" you mean it doesn't understand multipart, then it is severly flawed since end users may send the report as multipart/alternative with text/plain and text/html parts, or multipart/mixed with text/plain and the evidence attached (assuming they use a conventional MUA). On the other hand, if the software at the abuse desk handles multipart, (even though it does not reconize reports, or does not understand the ARF report type) it would be expected to treat some parts as attachments. In this case there would be a text/plain part (which introduces the report and instruct to see the other parts for the evidence), an unknown part (the ARF itself) and an "attached email" which is the evidence. I developed a piece of software for reporting the spam I receive. My procedure for reporting spam is: 1. sending ARF with full evidence attached and request a delivery notification. 2. if no acknologment is received, send ARF with a header only attachment (some ISP rejects the report because the attached evidence scores too high! I realized this because one of them was kind enough to reject the message in the SMTP conversation, instead of devnulling it). This issue usually also affects text/plain reports. Sometimes the problem is at the sending MTA, which if it implements outbound spam filters. 3. if I am explicitly informed there was an issue with the content type, I will send a text/plain message. Usually I just modify the Content-Type header and leave the content as ARF. 4. mantain per abuse desk statistics in order to avoid sending ARF to unresponsive abuse desks (I don't like to spam with spam reports!). In most cases I have either obtained a positive response by sending ARF, or I haven't received any response at all. About item 3, I first tried sending text/plain report when ARF+header seems to be ignored, but then I concluded this practice has little impact in the outcome of the reporting. Best Regards Javier Godoy ---------------- Universidad Nacional del Litoral Facultad de Ingeniería y Ciencias Hídricas Santa Fe - Argentina Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OEjxId003895 for ; Fri, 24 Jul 2009 07:46:04 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 8792080F62; Fri, 24 Jul 2009 07:10:11 -0700 (PDT) Message-Id: From: Steve Atkins To: Richard Conner In-Reply-To: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 24 Jul 2009 07:10:25 -0700 References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 00:35:30 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 07:46:04 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 14:46:04 -0000 On Jul 23, 2009, at 8:11 PM, Richard Conner wrote: > > I know that folks here are simply writing the RFC and not actually > dictating what people do with these reports when they get them, but > can anyone shed any light on whether abuse desks typically scrutinize > ARF reports to spot this sort of abuse? Would it be worth my time as > an end-user to figure out how to construct and send reports in this > form? If so, I'd be more than happy to give it a try. Abuse desks typically don't read ARF reports at all. That's sort of the point, as they're intended to be machine-readable and processed mechanically. Unless you have an agreed relationship with the ISP you're sending the report to, ARF is probably not the best format to use. Instead send plain text, with the message inline and a brief (5 line or less) intro telling them what the drop box is and why. There are people who send unsolicited reports to abuse@ in ARF format, but those reports are not treated in any way differently to any other email sent to abuse@. If the ticketing system being used to handle abuse@ doesn't handle MIME well, then the report in ARF format is far less use than one sent as plain text, and may well be ignored. This isn't ideal, but that's just how some abuse desk infrastructure is built. I know that at least a dozen major ISPs whose abuse desk ticketing systems will notice dropboxes and suchlike in any report they receive automatically, whether it's sent in ARF format or otherwise, but it's not something I'd want to rely on in general. Cheers, Steve Received: from corpmail.thindata.net (corpmail.thindata.net [64.34.52.38]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6ODt7Ae000527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jul 2009 06:55:13 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@thindata.com Received: from tor2.corp.thindata.net (corp.thindata.net [10.0.1.10]) by corpmail.thindata.net (8.13.7/8.13.7) with ESMTP id n6ODLtGT020813 for ; Fri, 24 Jul 2009 09:21:55 -0400 X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 corpmail.thindata.net n6ODLtGT020813 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 2009 09:21:54 -0400 Message-ID: <83005F77C514DA41B067EB6FFF7E715D1DEE93B7@TOR2.corp.thindata.net> In-Reply-To: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [feedback-report] Feedback types & e-mail drop boxes Thread-Index: AcoMFknDt8GA/VQhRzSMQSy8ALJMDwASnhpA References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> From: "Matthew Vernhout" To: "Richard Conner" X-Greylist: Delayed for 00:33:12 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 06:55:14 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n6ODt7Ae000527 Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:55:14 -0000 > This seems like malfeasance to me. I get a little > weary of freemail operators pretending to misconstrue my > complaints with the excuse that their servers didn't send the > message, and that they therefore have no problem to solve. I to have experienced this in the past - not only from hotmail... I know your frustration. > I wouldn't expect such a new Feedback Type to include or even > refer to the Reply-To address, but it could at least flag the > problem; perhaps it could be called "fraud-dropbox" or > something of the sort. AOL has an account specificly for this purpose - I agree it would be nice to see others pick up this practice too... Maybe MAAWG or OTA or (some other group?) would be a good place to bring this forth. Richard do you mind if I forward your note to the Anti-Phishing group within MAAWG? Thanks, MATTHEW VERNHOUT, CIPP/C Director, Delivery & ISP Relations ThinData The Email Authority. t: 416.361.3522 x238 e: mvernhout@thindata.com www.thindata.com Subscribe to our Email Strategies newsletter Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6OA51oA018907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jul 2009 03:05:07 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 4196 invoked by uid 100); 24 Jul 2009 09:05:00 -0000 Date: Fri, 24 Jul 2009 05:05:00 -0400 (EDT) From: John Levine To: Richard Conner In-Reply-To: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> Message-ID: References: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Delayed for 01:00:01 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 24 Jul 2009 03:05:07 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 10:05:10 -0000 > This seems like malfeasance to me. I get a little weary of > freemail operators pretending to misconstrue my complaints with the > excuse that their servers didn't send the message, and that they > therefore have no problem to solve. Indeed, but this is a policy rather than a technical issue. ARF already lets you do this: Reported-Domain: hotmail.com Reported-URI: mailto:dropbox@hotmail.com But so long as Hotmail's abuse department only has scripts that say "not from us", it doesn't matter what we send them. R's, John Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6O4CFmP028822 for ; Thu, 23 Jul 2009 21:12:20 -0700 Received: from [10.0.1.2] ([70.21.25.121]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KN900LWNNIH1VC0@vms173011.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Thu, 23 Jul 2009 22:11:06 -0500 (CDT) Message-id: <74419108-0AA3-4407-9457-9F523B0BD5BB@bellatlantic.net> From: Richard Conner To: abuse-feedback-report@mipassoc.org Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 23:11:05 -0400 X-Mailer: Apple Mail (2.935.3) X-Greylist: Delayed for 01:00:43 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 23 Jul 2009 21:12:21 -0700 (PDT) Subject: [feedback-report] Feedback types & e-mail drop boxes X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 04:12:21 -0000 Hello everyone. I was referred here by a response I got from Hotmail in trying to report an e-mail address (Reply-To) apparently used by a 419 fraudster. It seems that Hotmail is not receptive to these sorts of reports when the mail does not originate from Hotmail IP space. This seems like malfeasance to me. I get a little weary of freemail operators pretending to misconstrue my complaints with the excuse that their servers didn't send the message, and that they therefore have no problem to solve. At the risk of repeating what many of you doubtless already know: if a message can be confirmed to be a fraud pitch (typically not very hard to do), and it has a Reply-To that differs from the From/Envelope-From/ Return-Path etc., then this provides pretty strong evidence that the Reply-To is a **genuine deliverable address** (or at least is meant to be such by the fraudster), and not a forgery. I would think that a prudent and public-minded mail provider would want to weed out such addresses from its user population. I would not expect a single report from me to lead to an instant shutdown of such an address, but certainly if many such reports are received from many people they should carry a great deal of weight. I know that folks here are simply writing the RFC and not actually dictating what people do with these reports when they get them, but can anyone shed any light on whether abuse desks typically scrutinize ARF reports to spot this sort of abuse? Would it be worth my time as an end-user to figure out how to construct and send reports in this form? If so, I'd be more than happy to give it a try. I've scanned through (most of) your list archives and saw the discussion about defining "Reply-To" as a Feedback Type. I understand (and generally agree with) the objections to what would appear to be a redundancy (of repeating a field already present in the message packet source), but I think this very common model for e-mail abuse does deserve a bit more emphasis. Creating a distinct Feedback Type to cover this case would (in my uninformed opinion) be a service to recipients of ARF messages, since it would point them more precisely to the specific nature of the abuse being reported. Otherwise, it becomes tempting for them just to check the header and, seeing that the message did not come from their IP space, simply dismiss the report as ignorant or misdirected. I wouldn't expect such a new Feedback Type to include or even refer to the Reply-To address, but it could at least flag the problem; perhaps it could be called "fraud-dropbox" or something of the sort. Thanks for reading, Richard C. Conner, P.E. http://www.rickconner.net/spamweb/