On Wed, 27 May 1998, Greg A. Woods wrote:
> Date: Wed, 27 May 1998 21:29:50 -0400 (EDT)
> From: "Greg A. Woods" <woods@???>
> Reply-To: Exim Users Mailing List <exim-users@???>
> To: exim-users@???
> Subject: Re: [EXIM] OFF-TOPIC
>
> [ On Wed, May 27, 1998 at 14:45:22 (-0400), Dave C. wrote: ]
> > Subject: [EXIM] OFF-TOPIC
> >
> >
> > When a spam is received, most of us probably know how to pick out all
> > sorts of identifying information, IP addresses, etc out of the headers,
> > and figure out who to report the offense to (Eg, the dialup provider,
> > the provider of the advertised www page, the postmaster at the relay,
> > and perhaps abuse@ for the domains of any forged addresses included),
> > and we all hope for swift action by any concerned party.
> >
> > However, we all undoubtedly realize that the recipients of these
> > reports/complaints have (especially the admins at national "online
> > services" and national dialup providers) to sift thru a massive ton of
> > these things by hand, which certainly include a massive number of
> > duplicate reports of the same offender, but in different formats and
> > including different information.
>
> What could be more "standard" than just forwarding an exact copy of the
> spam as you received it, headers and all?
Since when are Received headers standard and automatically parseable?
My idea is so that cluefull people, can individuall look at the headers
of the spam they receive, and submit reports in a standardized,
parseable form, where the recipients can easily identify duplicate
reports of the same instance of abuse. If the abuser is using a
throwaway dialup account, and is using random SMTP relays all over the
globe, then the source IP address is not going to be in any standard,
programatically identifiable location in the headers of the received
message. But if the recipient can look for that IP in the headers, and
then put it in a "ABUSE-ORIGIN-IP: x.x.x.x" format, then it will be.
> There are at least two recognized *standard* ways to forward messages
> within the body of another message. I found out much to my horror that
> using MIME is *not* a good idea. Many people cannot see all the headers
> in such messages as their MIME viewers will strip out most of the
> interesting stuff (i.e. the "Received:" headers) [eg. Pine does this!].
> As a result I always use plain old RFC 934 format. (Some people think
> that RFC1153 would be an OK format too, but it's much more oriented to
> digests than 934 is.)
I'm not talking about readability or verifiability, I'm talking about
ability to programatically parse or sort large numbers of reports. The
final item in such a report would of course be the full original text
of the message including headers.
> If you forward a copy of your spam as an RFC 934 encapsulated message,
> complete with all headers, then *anyone* can read it with *any* mail
> reader. The recipient can then apply their own interpretation to the
> message and verify your claims directly. Assuming your mailer doesn't
> do something totally asinine, such as re-filling lines in the
> encapsulated message, then the recipient can do byte-for-byte
> comparisons with other copies they recieve in order to be sure they can
> identify common copies.
>
> In addition you can add a paragraph or two in your message to explain
> your interpretation of the events. Given that most of the spam I now
> receive directly is forwarded through unsuspecting open relay hosts, I
> usually include a couple of paragraphs similar to the following
> templates to both the relay host contacts (all of them), and the
> originating ISP (usually just the <abuse> address if I know it works):
>
> It would appear that the mailer at <host-I-recvd-directly-from>
> is susceptible to theft of service attacks. You probably want
> to fix this as soon as possible by either re-configuring,
> upgrading, or replacing your mailer.
>
> This attack would not likely have been possible if <source-ISP>
> had installed filters on their network to prevent their users
> from making unauthorized SMTP connections. Hopefully they can
> be encouraged to install such filters as soon as possible and I
> invite you to join me in applying such encouragement.
>
> Anything more than this would effectively require we all agree on the
> design and output format for an AI-like tool that would interpret the
> headers for us.
Nono, we (recipients making spam reports) use our own Real "I", to
interpret the headers, and then place it in a report than can be
processed by simple programs that dont have to have AI, to sort
duplicate reports together, not necesarrily to throw them away, but to
make the first report of a NEW incident more obvious than the six
hundred twenty fourth report of yesterday's spammer whose account we
have already terminated.
Currently admins have to manually inspect every message, which with a
box full of thousands of messages, could mean quite a while can go by
between the first person reporting a spam before they read it.
>
> --
> Greg A. Woods
>
> +1 416 443-1734 VE3TCP <gwoods@???> <robohack!woods>
> Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
>
> --
> *** Exim information can be found at http://www.exim.org/ ***
>
>
--
*** Exim information can be found at
http://www.exim.org/ ***
