[SpamCop-List] Re: New SpamCop parser?

[Mike Easter]

Furry Raccoon wrote:
> Mike Easter wrote:
>
>> It likes to receive the emailed spam *forwarded as an attachment* --
>> which has a completely different structure than an inline submission.
>> Inline submissions have some problems compared to the forward as
>> attachment.
>>
>> If 'we' - tinw - submitted notification items to an abuse desk
>> forwarded as an attachment instead of inline, the original spam item
>> would be just as 'viewable' and renderable and able to be
>> 'appreciated' as to their spam 'appearance' as the original item.
>>
>> When we - where we is the SC notification system - or even my manual
>> notifies - send a copy of a spam to a desk as an inline structure
>> instead of as an attachment, it is not an easy task for the desk to
>> take that item and recreate the original spam out of it.
>
> It was my understanding that when you have an e-mail and you go into
> 'view source', you are seeing exactly what was sent to you....Un-
> modified by the mail viewer since it is the 'source'.

Correct.

> If I just
> copied and pasted the version that is first displayed to me when
> I open the e-mail, I would expect that it would be much different
> having, as you said, line wraps etc... since it is modified to
> be more readable and viewable.

If you open the mail and your mailreader is availing itself of an html
rendering engine, such as the relationship between OE and IE's rendering
engine - it is a completely different deal about what you copy from
there.  No good.

> But I would expect that when I copy and paste that source to
> the spamcop 'process spam box', that it is getting the exact
> same info if I had sent that e-mail as an attachment to the
> spamcop parser.

That is correct.

>  If that isn't the case, I'll need more in-
> formation on what exactly is different to be able to properly
> address your reservations.

No.  My reservations aren't about what we send or submit to SC.  SC is
getting the 'pure' original item.

My 'issue' that I'm 'dredging' up to cause trouble ;-)  is that what SC
gets is good;  the original item, whether we paste it into the parser or
email it as an attachment - unless we are using some agent which screws
it up.  I'm referring here to the ideal kind of situation, such as that
of OE or similar such agents.

But down below, I'm addressing the fact that when it gets sent to the
abuse desk, it is not so perfect as what we give spamcop.

>> In the case of my manual notify, my mailuser agent has introduced
>> linewraps into the spam which weren't there in the original.  Also,
>> it is not easy for the desk to take what I have sent them and
>> 'render it up' to be a display of the original spam item.   The desk
>> would have to take what I have sent them and 'de-construct' my mail
>> to them, and then 'reconstruct' with some difficulty, the original
>> spamitem.  I know, because I have to do that all the time with
>> things which people post into the ng .spam.
>
> That could be due to the way the ng handles the information, or due
> to the way your newsreader interprets the ng information.  And again,
> I'm not entirely sure what the reporting desks have to do render up an
> in-line report versus an attachment report.  Any reponse to that
> concern would only be speculation on my part.

It is normal, standard procedure, for newsagents and mailagents to wrap
their plaintext.  If we put a spam inline into a message and send it
somewhere, it is going to get wrapped, whether we do it with a mailagent
like OE or with a newsagent like OE - or with virtually any other
mailagent for that matter.

However, I have never received a notify with a spam in it from SC, so I
don't know exactly what its mailagent does with the item.  I do know what
mine does.

>> That might have one form of importance vis the original headers - but
>> what is with the 'integrity' of the original body, anyway?
>> The fact is that it has been wrapped and all kinds of things and is
>> in no condition to be rendered or visualized.  The other issue is
>> that of the headers not being original either.  They have been bent
>> all over the place by the various influences on them.  Different
>> received spamitems which started out the same have been had all
>> kinds of different servers adding things.  Other different spamitems
>> have had all kinds of different spamfilters and virus filters and
>> such tacking things hither and yon.  If a desk is looking at the
>> headers of a 'bunch' of spams which originated there, the desk is
>> looking at a wide assortment of server influences on the original.
>
> The goal, I believe, is to keep the spam as unmodified as possible.
> Different influences that may alter the spam as it makes its way to
> your in-box can actually provide clues as to where it originated and
> how it got from point A to B.

Yes, I understand.  What I'm saying is that if I were an abuse desk and I
were receiving a manual notify from somebody like me who is sending the
notify with OE, I would rather receive the item the same way I send that
item to spamcop, forwarded as an attachment, not pasted into the body of
the notify inline.

I also think that SC notifies the abuse desk with such an inline copy,
instead of forwarding it as an attachment.

You see where I'm going?  SC and I both know that it is better to receive
a spam forwarded as an attachment rather than pasted into the body and
sent inline.  How come SC sends it to a desk like that?  How come SC
sends something to a desk in a condition which SC itself wouldn't find
acceptable?


-- 
Mike Easter
kibitzer, not SC admin