Subject: Re: [feedback-report] The limits of ARF, and INCH
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
Cc: ARF mailing list <[email-masked]>
Date: Wed, 29 Jul 2009 18:07:42 +0200
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

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/

Date: Wed, 29 Jul 2009 17:33:10 +0200
From: Alessandro Vesely <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] More Feedback-Types

Yakov Shafranovich wrote:
> On Tue, Jul 28, 2009 at 11:42 AM, Steve
> Atkins<[email-masked]> 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.

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 28 Jul 2009 11:49:27 -0400
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] More Feedback-Types

On Tue, Jul 28, 2009 at 11:42 AM, Steve
Atkins<[email-masked]> 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

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Tue, 28 Jul 2009 08:42:26 -0700
Subject: Re: [feedback-report] More Feedback-Types

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:[email-masked]

Spam with a dropbox?
     Feedback-Type: abuse
     Reported-URI:mailto:[email-masked]

>
> * 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

Date: Tue, 28 Jul 2009 16:22:01 +0200
From: Alessandro Vesely <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: [feedback-report] More Feedback-Types

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.

Date: Tue, 28 Jul 2009 07:48:21 +0200
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH
Reply-To: [email-masked]

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

Date: Tue, 28 Jul 2009 07:45:37 +0200
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tobias Knecht <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH
Reply-To: [email-masked]

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

From: "Murray S. Kucherawy" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>, Steve Atkins <[email-masked]>
Date: Mon, 27 Jul 2009 14:21:16 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] 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".

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 27 Jul 2009 16:23:43 -0400
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

On Mon, Jul 27, 2009 at 1:06 PM, Steve Atkins<[email-masked]> 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

Date: Mon, 27 Jul 2009 20:15:43 +0200
From: Tobias Knecht <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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"

--------------enig8D5546B9CE82DDD51210AB75--

Date: Mon, 27 Jul 2009 13:07:47 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

> 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

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 27 Jul 2009 10:06:56 -0700
Subject: Re: [feedback-report] The limits of ARF, and INCH

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

Date: Mon, 27 Jul 2009 18:54:59 +0200
From: Tobias Knecht <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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"

--------------enig6BFEE84AEA5F44FAC0D6D4EB--

Date: Mon, 27 Jul 2009 18:54:31 +0200
From: Tobias Knecht <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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"

--------------enig8FEE8BA7CF713B9D3784D241--

Date: Mon, 27 Jul 2009 12:19:46 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

> 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

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 27 Jul 2009 09:08:53 -0700
Subject: Re: [feedback-report] The limits of ARF, and INCH

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

From: "Murray S. Kucherawy" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 27 Jul 2009 08:42:29 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [feedback-report] IETF Standardization and ARF Version Number

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Yakov Shafranovich
> Sent: Monday, July 27, 2009 6:49 AM
> To: [email-masked]
> 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.

Date: Mon, 27 Jul 2009 17:17:43 +0200
From: Tobias Knecht <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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"

--------------enig0AAAF8FD4AE05AF449354584--

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 27 Jul 2009 10:41:03 -0400
To: Tobias Knecht <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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 <[email-masked]>:
> 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
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>
>

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 27 Jul 2009 10:25:03 -0400
To: [email-masked]
Subject: [feedback-report] FWD: Proposed IETF WG charter for "arf"

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 <Lisa.Dusseault at messagingarchitects.com>
        Alexey Melnikov <alexey.melnikov at isode.com>

   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

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 27 Jul 2009 09:49:02 -0400
To: [email-masked]
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?

Also, on a related note, it might be prudent to change the version
number to "1.0"?

Yakov

Date: Mon, 27 Jul 2009 15:25:59 +0200
From: Tobias Knecht <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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"

--------------enigC09A348184AE1FF90F2C32DC--

Date: Sun, 26 Jul 2009 18:39:53 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Richard Conner <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

> 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.

From: Richard Conner <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Sun, 26 Jul 2009 16:42:31 -0400
Subject: Re: [feedback-report] The limits of ARF, and INCH

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

Date: Sun, 26 Jul 2009 22:14:20 +0100 (BST)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

> 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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

Date: Sun, 26 Jul 2009 23:11:11 +0200
From: Tobias Knecht <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] The limits of ARF, and INCH

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, [email-masked], 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
> [email-masked]
> 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"

--------------enig9FE9286406F8DCD87AE1DC1F--

Date: Sun, 26 Jul 2009 22:08:50 +0100 (BST)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

> 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

From: Richard Conner <[email-masked]>
To: [email-masked]
Date: Sun, 26 Jul 2009 15:48:28 -0400
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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

Date: Sun, 26 Jul 2009 22:48:20 +0200
From: Tobias Knecht <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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"

--------------enig235058E4475DBC45FC15FA2A--

Date: Sun, 26 Jul 2009 22:38:15 +0200
From: Tobias Knecht <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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"

--------------enig98A48C91D878F2CA0F04D9DA--

Date: Sun, 26 Jul 2009 20:00:31 +0100 (BST)
From: "John R. Levine" <[email-masked]>
To: ARF mailing list <[email-masked]>
Cleverness: None detected
Subject: [feedback-report] The limits of ARF, and INCH

>>> 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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Sun, 26 Jul 2009 10:30:19 -0700
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

On Jul 26, 2009, at 9:26 AM, Murray S. Kucherawy wrote:

>> -----Original Message-----
>> From: [email-masked] [mailto:abuse-
>> [email-masked]] On Behalf Of Tobias Knecht
>> Sent: Saturday, July 25, 2009 3:06 AM
>> To: John R. Levine
>> Cc: [email-masked]
>> 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

From: "Murray S. Kucherawy" <[email-masked]>
To: Tobias Knecht <[email-masked]>, "John R. Levine" <[email-masked]>
Date: Sun, 26 Jul 2009 09:26:45 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Tobias Knecht
> Sent: Saturday, July 25, 2009 3:06 AM
> To: John R. Levine
> Cc: [email-masked]
> 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"?

Date: Sat, 25 Jul 2009 12:05:47 +0200
From: Tobias Knecht <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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"

--------------enig0F2812034677EFDB74086E4C--

From: Richard Conner <[email-masked]>
To: [email-masked]
Date: Fri, 24 Jul 2009 18:27:58 -0400
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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

From: Richard Conner <[email-masked]>
To: "Matthew Vernhout" <[email-masked]>
Date: Fri, 24 Jul 2009 17:50:31 -0400
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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

From: Richard Conner <[email-masked]>
To: [email-masked]
Date: Fri, 24 Jul 2009 17:46:25 -0400
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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:[email-masked]

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

Date: Fri, 24 Jul 2009 23:30:42 +0100 (BST)
From: "John R. Levine" <[email-masked]>
To: Richard Conner <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

> 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

From: Richard Conner <[email-masked]>
To: [email-masked]
Date: Fri, 24 Jul 2009 18:23:19 -0400
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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

Date: Fri, 24 Jul 2009 23:14:19 +0100 (BST)
From: "John R. Levine" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cleverness: None detected
ReSent-Date: Fri, 24 Jul 2009 23:14:33 +0100 (BST)
ReSent-From: "John R. Levine" <[email-masked]>
ReSent-To: ARF mailing list <[email-masked]>
ReSent-Subject: Re: [feedback-report] Feedback types & e-mail drop boxes
ReSent-Message-ID: <[email-masked]>
ReSent-User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

> 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, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

From: "Javier Godoy" <[email-masked]>
To: "Steve Atkins" <[email-masked]>
Date: Fri, 24 Jul 2009 15:57:01 -0300
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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

From: Steve Atkins <[email-masked]>
To: Richard Conner <[email-masked]>
Date: Fri, 24 Jul 2009 07:10:25 -0700
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

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

Content-class: urn:content-classes:message
Date: Fri, 24 Jul 2009 09:21:54 -0400
From: "Matthew Vernhout" <[email-masked]>
To: "Richard Conner" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

> <soapbox>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.</soapbox>

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: [email-masked] 
www.thindata.com 

Subscribe to our Email Strategies newsletter
<http://www.thindata.com/greatideas/newsletter/subscribe.asp>

Date: Fri, 24 Jul 2009 05:05:00 -0400 (EDT)
From: John Levine <[email-masked]>
To: Richard Conner <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] Feedback types & e-mail drop boxes

> <soapbox>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.</soapbox>

Indeed, but this is a policy rather than a technical issue.  ARF already 
lets you do this:

Reported-Domain: hotmail.com
Reported-URI: mailto:[email-masked]

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

From: Richard Conner <[email-masked]>
To: [email-masked]
Date: Thu, 23 Jul 2009 23:11:05 -0400
Subject: [feedback-report] Feedback types & e-mail drop boxes

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.  
<soapbox>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.</soapbox>

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/