Re: Opera won't play with Spamcop, hashes headers

Lane Gray, Czar Castic wrote:
> "Mike Easter"

>> I'm reading in the Opera ng/s^1 that redirect is /supposed to/
>> function as forward as attachment does in OE, but I'm reading an
>> Opera person saying in the forums^2 that redirect doesn't work like
>> that.
>>
>> Have you tried redirect?  How about doing one of those and posting
>> the tracker, even if it doesn't work so that we can find out if
>> redirect is working like the person in the opera ng sez or like the
>> forum person sez.

>> "Then Redirect sounds like what you want.  The message will keep the
>> ole headers basically unchanged, and the receiver will see the
>> message as sent from the spammer.

>> "Redirect removes the headers and just pastes the body into a fresh
>> email."

> The person from the forum had it right.  Redirect made the SC parser
> hack and cough, to wit:

The person from the forum didn't understand the whole picture with his
simple statement;  so he didn't have it right.

This is being quite helpful for an understanding of your Opera's
redirect function, but we are also causing problems here.  I was hoping
for a tracker.  Unfortunately those headers also contain your submit
address which should be kept a secret.

The effect of the redirect is not the same as OE's forward as
attachment, and it is also not what I expected to see.  It is a very
strange chimera of the original headers merged with a new set of
headers.

I'm posting a tracker for what you posted here, which would have been a
better way to do it.

http://www.spamcop.net/sc?id=z786829437z4165d4e9ee0021a7167d3ffc0b055002z

> SpamCop encountered errors while saving spam for processing:
> SpamCop could not find your spam message in this email:

The tracker shows a merging of the headers of the original spam with the
headers of your mail to SC, sorta like what would happen if your system
[ie mailbox] were forwarding a mail to SC's submit address.

  Abbreviated Received lines *comment
  from (sc-smtp1.eq.ironport.com [192.168.18.81]) by
sc-app3.eq.ironport.com
  from ms-smtp-01.rdc-kc.rr.com (24.94.166.115) by
sc-smtp1.eq.ironport.com
  from stylgar (CPE-69-76-185-251.kc.res.rr.com [69.76.185.251]) by
ms-smtp-01.rdc-kc.rr.com
  from 127.0.0.1 (AVG SMTP 7.0.323 [267.8.16]) *timestamp1
  from zaq.ne.jp (zaq3d2e6475.zaq.ne.jp [61.46.100.117]) by
lamx02.mgw.rr.com *timestamp2

So SC can't tell where the headers in your mail to the submit address
stop and the headers which were originally those of the spam begin.

Because I'm a human and not an algorithm, I can see that the source of
the original item was 61.46.100.117 rDNS zaq3d2e6475.zaq.ne.jp which is
SC blocklisted.

The Received tracelines are 'broken' in the next to the last line above,
or #4 down in a 5 line set.  The top 3 are from you to SC, the 5th was
the only one in the original spam.

> Nope.  "C" to put the whole thing in the clipboard, pasted into a new
> email with linewrapping turned off seems the only way to go.

Only is a strong word;  I would choose 'best' for an immediate solution.
I'm surprised at this result.

I expect that one could configure a mailhost to accomodate this strange
behavior of this Opera.  It would seem that a mailhost might 'train' SC
to accept/ignore the line marked '*timestamp1' above as part of a
mailhost configuration so that it could get past it to the next line.
That line is broken in that it is a non-compliant Received traceline and
doesn't have a 'by' field -- causing SC to break the chain right there
to name your own IP.

Back to the problem of exposing your submit address which is supposed to
remain a secret as it is to be only used by you.  It is possible for an
evildoer who wanted to cause you trouble to submit 'bad' reports under
your submit address, and when discovered it could cause you to lose your
SC privileges.  It would be better to keep your submit address a
secret -- once a secret is out, you should get rid of the old submit
address and get a new one.  You would do that by using the same form
where you signed up   http://www.spamcop.net/anonsignup.shtml  if you
are free "This is a free SpamCop account. You may re-run this free
authorization whenever you need to. If you do, any previous
authorization information associated with your email address will be
deleted."

If you are not free, you handle the problem of getting a new submit
address a little differently I think.


-- 
Mike Easter
kibitzer, not SC admin