Subject: [Asrg] 7. BCP - Abuse Reporting standard

From: "Jon Kyme" <[email-masked]>
Date: Tue, 06 Jan 2004 09:10:08 +0000

On NANAE, there's a group working on a "standard spam reporting" format
(see http://www.tmisnet.com/~strads/spam/bcp.html )

This is probably the kind of thing that should be invited to come under the
ASRG BCP sub-group - if we still have one. Should we (and by 'we' I mean
the chairs) be making more of an effort to recruit this kind of community
initiative to come and work under aegis of ASRG?

Personally, I don't think it's quite there yet - a RFC1894 message strikes
me as an obvious kind of thing - but it looks like a good start. There's
scope for interaction with LMAP I should think.

--

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 06 Jan 2004 14:57:12 -0500

> scope for interaction with LMAP I should think.

We actually have been discussing this. I have also been thinking about 
using something like DSNs for this, with one part for human readable 
data, another part for machine-readable and a copy of the original message.

However, the problem seems to me that there is much more than simple 
email abuse here. This format can be used for reporting spam messages. 
What about open relays, hijacked computers, spam websites, false domain 
registrations, etc.? All of these play a large part in the spam world 
and SpamCop for example, reports URLs regularly. Some of this overlaps 
with the workd of INCH and IDWG at the IETF.

So the question to me is more of scope - what scope should this subgroup 
have? Something that focuses solely on reporting spam messages 
themselves can be easily done with some kind of DSN-like format. BUT, if 
you want to report IPs, URLs, domains, and even perhaps include trace 
information on the spammer's companies, that is something much bigger, 
and requires different players.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"But in this world nothing can be said to be certain, except death and 
taxes" (Benjamin Franklin)
-------

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 06 Jan 2004 17:24:29 -0500

> with the workd of INCH and IDWG at the IETF.

  If it's useful, I'm willing to either supply data, or forward parts
of the spam arriving at my domain.

  Be warned, though, last time I checked, it was ~2 million messages a
day.

> and requires different players.

  For open proxies/relays/abused machines, a combination of src IP,
HELO/EHLO, and time is a reasonable start (i.e. basically information
used in greylisting).  Content doesn't matter as much if you *know*
the network connection is being abused, as you'll always get the same
content in a message you didn't block. :)

  For low-volume spam from non-abused machines, content filters are a
reasonable approach.

  The problem I have with any kind of coordinated reporting mechanism
is that it's probably more expensive than coordinating a switch to a
different port, with additional restrictions.

  Even ephemeral ports would be useful.  A signed UDP packet could be
sent by an originator, saying "I've got X amount of data, with Y
charactestics for you, and whitelist W says I'm a good guy".  The
recipient then responds with a port number specific to (originator,
time, etc.)

  It would be a while to set up, but no less work than the ongoing
slog of content filtering email, and coordinating the reporting of
abuse.  But because content filtering is the "status quo", people are
unwilling to change to another system, until the current one
collapses.

  Alan DeKok.

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 06 Jan 2004 22:54:24 +0000

> > (see http://www.tmisnet.com/~strads/spam/bcp.html )

YS > We actually have been discussing this. I have also been thinking about
> have? 

Well it's right with the charter - "to facilitate management responses to
spam activity"
and "to help network managers identify and deal with sources of spam on
their networks"

>Something that focuses solely on reporting spam messages 

I don't see a massive problem with coming up with sub-types (or
sub-sections?) of a spam-response DSN-like message which would cover the
types of report you identify.

The cited document suggests that reports may be sent to the "designated
reporting address" for:
     1.  The point of origin (determined from the headers)
     2.  Email drop boxes (if implicated)
     3.  Web sites (if implicated)
     4.  Regulatory authorities (if available)
     5.  Spam tracking services / block lists (if desired)
     6.  Online repositories
     7.  Other implicated parties (trademark protection)

All these kinds of reports are aimed at spam-reduction. If done right,
could be useful. If they're done wrong, they can be pretty spammy
themselves.

I'm interested - I wrote an "abusebot" which handles rather a lot of
(mainly) spurious abuse reports for a bunch of domains I'm responsible for.
A standard format would make automated responses easier to do and simplify
the consequent human workload. My attention was drawn to this by an abuse
reporter who sent us some stuff (with some tool I guess) - It took a while
to figure out why we got the report, even the reporter didn't know why at
first. I was able to tell him that he'd sent us the report because a
spamvertised website had an address in one of our domains as the technical
contact (in the whois).

--

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 06 Jan 2004 23:02:41 +0000

YS> Some of this overlaps 
> with the workd of INCH and IDWG at the IETF.

Sorry, missed that. "Intrusion", "Computer security incidents"
hmm, maybe - at a stretch. Do we know if those groups would consider this
their patch? Or is this just a "feeling"?

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 06 Jan 2004 20:37:26 -0500

> their patch? Or is this just a "feeling"?

We will coordinate with them, however their goals are different. There 
is some small overlap - hijacking a computer or using an open relay is 
an intrusion.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Among all our enemies / The ones to be most feared are often the 
smallest" (Jean de la Fontaine)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 06 Jan 2004 20:48:28 -0500

Alan DeKok wrote:
...
> different port, with additional restrictions.

This is not a coordinated mechanism - its just a standard for abuse 
reports. Such abuse reporting standard is intended mainly to make the 
ISPs' jobs easier and spam reporting more automated. For example, if 
such standard was implemented, abuse reports coming to an ISP can be 
automatically parsed into their helpdesk systems, saving time required 
to read and transcribe them. This can definatly free up time for the 
ISPs to go after the spammers themselves.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"One who watches the wind will never sow, and one who keeps his eyes on 
the clouds will never reap" (Ecclesiastes 11:4)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 06 Jan 2004 20:53:53 -0500

Jon Kyme wrote:

> Yakov Shafranovich wrote:
 >

We need to draw a balance between the time required to define and 
implement such standard, and what it would cover. The larger the 
standard, the more time it will take to do it. Therefore, I would rather 
see something with a more narrow focus, and possibly extensible, rather 
than something broad that will take forever to implement.

>      7.  Other implicated parties (trademark protection)

For example, regulatory authorities such as the FTC might be interested 
in information that a regular ISP will not care for. The problem that I 
see is determining what the standard should cover, and the parties 
involved, making sure that its narrow enough to be implemented quickly 
and broad enough to make a difference while keeping all of the involved 
parties happy and benefiting from it.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: John Levine <[email-masked]>
Date: 7 Jan 2004 05:05:46 -0000

>(see http://www.tmisnet.com/~strads/spam/bcp.html )

I'd certainly like to come up with a standard abuse report, although I
have to say the proposal on that web page leaves a lot to be desired.

The most likely container format would be XML, since it's a reasonable
format for tagged values, there's plenty of existing software to create
and parse it, and it's widely used in other RFCs already.

The researchy bits are partly to figure out what items a report needs
to contain, whether it works better to do one report per spam or to
collect multiple similar spams, and how best to deal with the desire
of some reporters to provide less than full information in their
reports.  It might also make sense to standardize some responses,
e.g., accepted/problem solved, accepted/problem identified but not yet
solved, accepted/problem not identified, rejected/not from us,
rejected/insufficient information, rejected/queue full so try later.
We'd also need to be sure to avoid needless incompatibility with the
intrusion and incident WGs.

Although the most likely way to pass these things around would be as
MIME parts in e-mail messages to abuse desks, I wouldn't want to rule
out other transmission methods.  I could easily imagine that large
ISPs might want fast dedicated channels so the could do real-time
problem analysis and resolution and maybe even detect and stop a spam
run in progress.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Art Pollard <[email-masked]>
Date: Tue, 06 Jan 2004 22:27:58 -0700

I agree with John.  Furthermore, I think it is a great idea and should be 
pursued.

I use Eudora for my Windows mail client (so I don't suffer from all the 
trojans that are so prolific with Outlook).  When I try to forward spam to 
the various abuse departments, Eudora almost always if it is HTML mail 
succeeds in munging the original message sometimes making me wonder how 
useful it is to the abuse department.  (This is caused by the HTML being 
loaded into Eudora and then being saved back out again -- as if it were 
composed in Eudora and not in its original format.)  I wouldn't be 
surprised if this were not an isolated case as far as mail readers go.  The 
standard should ensure that the original spam is sent back to the abuse 
department in its entirety including full headers obviously and not some 
reconstruction by the mail client.

I think that Mime parts would be the way to go.  Furthermore, I think a 
standard reporting address should be specified.  Most have settled on 
[email-masked] but not all and it is only an informal standard at best.

If an ISP were able to in real time analyze the complaints, they could 
compare the messages that were forwarded in the complaints against outgoing 
mail streams and quickly isolate which user is sending the offending 
messages.  This could be done by any number of means the most obvious would 
be some sort of Bayesian or vector space model filtering.  In either case, 
it would not be too difficult to automate to some degree relieving the 
abuse department from much of the load.

-Art
-- 
Art Pollard
http://www.lextek.com/
Suppliers of High Performance Text Retrieval Engines.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 07 Jan 2004 12:02:51 +0000

Art Pollard>  
> [email-masked] but not all and it is only an informal standard at

I think "abuse" is pretty much the de facto standard, supported by rfc2142,
adopting anything else would take some justifying.

--

---

From: "Tom Bartel" <[email-masked]>
Date: Wed, 7 Jan 2004 10:19:05 -0700

Should the abuse reporting standard also cover inquiries regarding email
that should be getting through but is not?  I understand that the intent
is to facilitate abuse complaints for spam received, but the other side
of the coin - regardless of what becomes standard for regulating email
delivery (encrypted email, sender authentication, consent system,
etc...), is that much contact may need to be made for email that is
failing to be appropriately delivered. 

Should the Abuse Reporting Standard also coordinate inquiries about mail
failing delivery, whether by systematic failure, intentional blocking,
or whatever by that ISP?  

The intent of an abuse reporting standard would be to allow ISP's to
efficiently handle complaints.  Regarding email delivery failure, would
a uniform and well-formed inquiry into the ISP at the appropriate place
so their abuse staff can manage it appropriately be useful as well?  

ISP's have generally been happy to provide such information.  Yahoo! for
example has a specific address, [email-masked] where they
accept these inquiries as well as some web forms.  

http://help.yahoo.com/help/us/mail/bulk/bulk-01.html
http://add.yahoo.com/fast/help/us/mail/cgi_bulkmail
http://help.yahoo.com/help/us/mail/defer/defer-01.html  
http://add.yahoo.com/fast/help/us/mail/cgi_defer 

Having a common standard seems like a good thing.

Thx!

Tom 
Tom Bartel
303.642.4104

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Art Pollard
> Sent: Tuesday, January 06, 2004 10:28 PM
> To: John Levine; [email-masked]
> Subject: Re: [Asrg] 7. BCP - Abuse Reporting standard
> 
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.558 / Virus Database: 350 - Release Date: 1/2/2004

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 07 Jan 2004 18:32:43 +0000

> that should be getting through but is not?  

No, of course not.

> I understand that the intent

That's what the postmaster role is for.

--

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 8 Jan 2004 02:01:41 +0100

> adopting anything else would take some justifying.

Yes, but abuse @ whatdomain?
The most reliable information is the IP address from which the spam 
was injected into my system.

------------------------------------------------------------------------
h68-146-73-40.cg.shawcable.net:68.146.73.40 rbl-allowed:
    <[email-masked]> to <[email-masked]>
Looking up 68.146.73.40 with whois.arin.net is fine:
    OrgAbuseEmail:  [email-masked]
------------------------------------------------------------------------

Let's try another one:
------------------------------------------------------------------------
customer-hmo-61-203.megared.net.mx:200.77.61.203 rejected:
    <[email-masked]> to <[email-masked]> badrcptto
  Comment:  This IP address range is under LACNIC responsibility for further
  Comment:  allocations to users in LACNIC region.
  Comment:  Please see http://www.lacnic.net/ for further details, or check the
  Comment:  WHOIS server located at whois.lacnic.net

At least there is
  ReferralServer: whois://whois.lacnic.net

$ whois -h whois.lacnic.net 200.77.61.203

and now?
------------------------------------------------------------------------

The LACNIC example also holds for e.g. RIPE and leads to things like:

remarks: ---------------------------------------------------------
remarks: Please send abuse and spam notifications to [email-masked]
remarks: ---------------------------------------------------------

trouble: SPAM/COMPLAINTS to: [email-masked]
trouble: SPAM/COMPLAINTS to other addresses will probably be ignored.

remarks: ************************************************************
remarks: * ABUSE CONTACT: [email-masked] IN CASE OF HACK ATTACKS, *
remarks: * ILLEGAL ACTIVITY, VIOLATION, SCANS, PROBES, SPAM, ETC.   *
remarks: ************************************************************

remarks: Please send abuse notification to [email-masked]

(I think you get the idea) while other have no abuse contact at all.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: John Levine <[email-masked]>
Date: 8 Jan 2004 02:10:27 -0000

>that should be getting through but is not?

It's a reasonable topic but I think we should drain one swamp at a
time.  The kind of stuff you'd put in a spam report is rather
different from what you'd put in a non-delivery report.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: GertJan Hagenaars <[email-masked]>
Date: Wed, 7 Jan 2004 22:22:45 -0500

Apparently, Markus Stumpf wrote:
% On Wed, Jan 07, 2004 at 12:02:51PM +0000, Jon Kyme wrote:
% > I think "abuse" is pretty much the de facto standard, supported by rfc2142,
% > adopting anything else would take some justifying.
% 
% Yes, but abuse @ whatdomain?
% The most reliable information is the IP address from which the spam 
% was injected into my system.
% ------------------------------------------------------------------------
% h68-146-73-40.cg.shawcable.net:68.146.73.40 rbl-allowed:
%     <[email-masked]> to <[email-masked]>
% ------------------------------------------------------------------------

In this case, how about [email-masked] as a first try?

CHeers,
GertJan.

-- 
+++++++++++++ -------- +++++ --- ++ - +0+ + ++ +++ +++++ ++++++++ +++++++++++++
sed '/^[when][coders]/!d         G.J.W. Hagenaars -- gj at hagenaars dot com
    /^...[discover].$/d          Remembering Mike Carty 1968-1994
   /^..[real].[code]$/!d         UltrixIrixAIXHPUXSunOSLinuxBSD, nothing but nix
' /usr/dict/words                I'm Dutch, what's _your_ excuse?

---

From: Art Pollard <[email-masked]>
Date: Wed, 07 Jan 2004 20:25:57 -0700

>adopting anything else would take some justifying.

Perhaps.  However, when I am in the "reporting mood", I often find places 
which do not use "[email-masked]" and instead use anything from 
postmaster@, support@, spam@, or a whole host of other addresses.  They 
often have this information buried on some support web page making it all 
the more difficult to find.  On the other hand, perhaps that is the point.

In either case, while most use [email-masked], there still are 
surprisingly many who do not.

-Art

---

From: John Levine <[email-masked]>
Date: 8 Jan 2004 03:49:47 -0000

>postmaster@, support@, spam@, or a whole host of other addresses.

You know, that's exactly why I run abuse.net.

In any event, if we have a standard format, the networks that want it
will surely tell us where to send it.  Maybe it'll be abuse, maybe
it'll make sense to invent a new address like autoabuse, but that's
a detail.

Regards,

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 08 Jan 2004 09:19:54 +0000

> was injected into my system.

I believe the question of inadequate whois data is being addressed
elsewhere. Or is your proplem that operators solicit reports pertaining to
spam at one particular address (not 'abuse') yet support the 'abuse'
address for other network abuse?

--

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 08 Jan 2004 09:34:22 +0000

> postmaster@, support@, spam@, or a whole host of other addresses.  

No, but they should. 

> surprisingly many who do not.

Well, there's a topic for research - what proportion of operators don't
support 'abuse' for this purpose?
What proportion don't support 'abuse' at all?
How many have got themselves on rfc-ignorant :-)

A reporting standard would help operators route reports to whatever
internal units they wish. Provision of the abuse address is a community
requirement.

--

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 08 Jan 2004 09:37:02 +0000

>You know, that's exactly why I run abuse.net.

And very useful it is - which reminds me - I may have a few more domains to
register - I'll just check :-)

--

---

From: Andrzej Filip <[email-masked]>
Date: Thu, 08 Jan 2004 12:07:11 +0100

Markus Stumpf wrote:
> [...]

One possible solution would be to require RP (responsible person) DNS 
records in reverse DNS zones of */24 and */16 nets.

Two contact addresses make sense:
* abuse
* netmaster

e.g.

abuse     IN RP ip-abuse.some.domain.  abuse-txt-record.some.domain.
netmaster IN RP ip-netmaster.some.domain.  nm-txt-record.some.domain.
@         IN RP mailbox.some.domain.  txt-record.some.domain.

The last record (with name the same as domain name) would be used as 
fall back for both abuse and netmaster. It would allow using wildcard RP 
records with exceptions for some addresses (or some */24 nets in case of 
wildcard */16 RP records).

Implementation path/enforcement:
Some MTAs may refuse to accept messages from nets with no RP records and 
bad record in spamcop (or similar).

-- 
Andrzej [pl>en: Andrew] Adam Filip http://anfi.freeshell.org/
[email-masked] [email-masked] [former: [email-masked]]

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 08 Jan 2004 14:16:19 +0000

> Two contact addresses make sense:

This is an interesting idea - but somewhat orthogonal to a standard for the
*matter* of an abuse report. Which is, I guess, why you forked the thread.

This is the kind of data traditionally held in the whois - standardisation
in this area has been (is) difficult - I hear. Some of the registries and
registrars have "difficulties".

As I understand it, RP gives us someone to contact in response to a host
malfunction - I'm not sure that your proposed usage stretches this a bit?

I'd like to sidestep all this by assuming that the reporter has obtained
(by an unspecified mechanism) a suitable address as the target for the
report. If a reliable and foolproof mechanism can be put in place for the
address discovery - so much the better.
But it's a separate issue.

--

---

From: Andrzej Filip <[email-masked]>
Date: Thu, 08 Jan 2004 17:45:32 +0100

Jon Kyme wrote:
>>>>I think "abuse" is pretty much the de facto standard, supported by
>>
>>rfc2142,
>>

I would not call it orthogonal, "where should the report go" is a 
separate but closely related issue worth starting a sub-thread.

> registrars have "difficulties".

IMHO problems with single simple worldwide whois set of standards and 
keeping all the whois data "up to date" justify creation of simpler 
"email contact" standard. Whois data are managed by "a third party", 
reverse DNS is managed almost always by ISP or direct IP zone user.

Abuse reporting standard makes sense if it would allow automatic 
submission/processing including fully automatic finding of right 
destination of the report.

> malfunction - I'm not sure that your proposed usage stretches this a bit?

May be a little bit.
The idea is to put email contact info into reverse DNS zones 
[*.in-addr.arpa] - IMHO RP record is the best choice for such task.

> But it's a separate issue.

So treat this sub-thread as a separate thread :)

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 08 Jan 2004 10:24:17 -0800

>>(see http://www.tmisnet.com/~strads/spam/bcp.html )
I'm BCCing George, the author in case he's not aware; bet he's interested.

>have to say the proposal on that web page leaves a lot to be desired.
This is probably why it ran out of steam.  There's been no further 
discussion for ages, so I think there would be no objection to ASRG 
taking over.

A MIME or XML format seems problematic, as most reports come from end 
users.  How are end users going to file reports in a format that their 
MUAs don't readily support? (Readily. Yes, they can type XML directly, 
or manually add various MIME attachments to each report, but that's 
unreasonable.)
Let's KISS.  There should be one format, and it should be simple enough 
that an abuse desk's claim that it was too complex would strike most 
anyone as unreasonable too. There'd be a bunch of predefined types, but 
others would be allowed (could be IANA managed, e.g. like the Sieve mail 
filter extension namespace, but that's probably overkill).

     Format: AR 2.0  (A new suggestion I'm making: Include a string that would identify an automatically parsable report.)
     Attn:  [email-masked]
     Type:  dropbox
     Re:  [email-masked]
     etc.

--------------------------------
Ideally we should work with the developers of *Abuse-queue management 
tools*, e.g.

    * Abacus <http://word-to-the-wise.com/abacus/index.html> commercial
      ticketing/tracking system designed specifically for abuse desks
    * Kana <http://www.kana.com/> commercial Customer Relations
      Management tool
    * Remedy <http://www.remedy.com/> commercial Customer Relations
      Management tool
    * Request Tracker <http://www.bestpractical.com/rt/> (RT and RT2)
      open-source ticketing tool
    * AbusePipe <http://www.crystalsoftware.com.au/analyzespam.html>
      automated abuse handling software.

source: http://www.spamcop.net/fom-serve/cache/352.html
-----------------------------------
How spamcop chooses where to route reports is discussed at
http://www.spamcop.net/fom-serve/cache/94.html  in some detail.
Read how it uses netblock size, whois records, and abuse.net entries.
Given the volume of reports SpamCop sends, it's probably as good as it 
gets, and builds on rfc 2142.  (Please, no SpamCop criticism based on 
hearsay or *outdated* info on how it used to work; on-topic comments on 
how you know it works currently only, Please!)
Excerpt:

*...[For Large Networks,] *SpamCop now bases its routing of reports 
mainly on "whois records" - ... Normally, when SpamCop encounters a NOC 
role account such as "hostmaster@ or noc@" in the whois records, it will 
check with abuse.net for a valid abuse contact instead of sending 
reports to your NOC role account. If...

*Abuse.net*

All abuse desks should register an email address for the domains they 
manage with abuse.net. SpamCop will use this information to try to route 
reports correctly. We...
--------------------------------
As an appendix, here's Spamcop's format.  It's well defined enough to be 
readily parsable.

Starts off: 
--
[ SpamCop V1.3.4 ]
This message is brief for your comfort.  Please use links below for details.
--
Then content depends on the type of abuse, e.g. : 
--
Email from 0.0.0.0 / Sat, 20 Dec 2003 17:06:50 -0800 (PST)
http://www.spamcop.net/w3m?i=z5554050munged4c99f7z

[ Offending message ]
--
and/or
--
Spamvertised website: http://ama.sent.dom
http://ama.sent.dom is 0.0.0.0; Fri, 26 Dec 2003 06:17:47 GMT
http://www.spamcop.net/w3m?i=z56477868munged53cf9bd88517fez

[ Additional comments from recipient ]

[ Offending message ]
--
and/or
--

User-targeted report, see notes, if any.
http://www.spamcop.net/w3m?i=z4944731munged36df8b9z

--
Here's a format that SpamCop formerly sent; last I checked, it doesn't 
report Spamvertised email addresses any more.
--

http://spamcop.net/w3m?i=z254904157zb4amunged1c30c3e9cz
Spamvertised email address: [email-masked]

>> [email-masked] is 0.0.0.0; Wed, 21 May 2003 08:12:33 GMT
>  
>
-- 

Followed by the (often munged) SUBE header and body.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 08 Jan 2004 13:52:38 -0500

...

We will be forming a subgroup on this shortly. Stay tuned for more 
information.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: "Jon Kyme" <[email-masked]>
Date: Fri, 09 Jan 2004 00:03:25 +0000

> MUAs don't readily support? (

Well, the obvious way of supporting some format not directly supported by a
standard MUA is to make some other tool available...

...as spamcop does - as you say. Make it simple for the reporter, sure, but
by making good tools. The report format needs to fit the needs of the
recipient - primarily.

Yes indeed. See above.

--