[SC-Help] Re: SpamCop doesn't parse routing info correctly

[Mike Easter]

Tristan Miller wrote:

>  I figure it's best to
> tell everyone to report the problem to SpamCop and hope that Yahoo!
> and/or his ISPs permanently suspend him for TOS violations.

Considerting some of the elements of this particular issue, ie he is a
known and identifiable meatspace identity who sounds pretty whacky such
that the recipients of his missives consider him to be mentally ill -- 
and have for some time -- and that he posts from the Arizona Health
Sciences Library IP via yahoo webmailer accounts.  I find myself
wondering if his composing and mailing these essays might be
'therapeutic' for him.

> When the automated mailhosts configuration failed, the SpamCop web
> page gave me an option to request manual configuration by a SpamCop
> administrator.  They call this a "waiver".

Hmm.  Interesting use of the word.

>>> SpamCop now correctly identifies the University of Arizona IP for
>>> the spam.
>>
>> Not according to what I see at your originally posted employer's
>> header example
>>
http://www.spamcop.net/sc?id=z919793041z85093855a4505837202f64fc298ebaa6z
>
> That was an old submission.  Submissions made after mailhosts
> configuration are processed correctly.

When I parsed that tracker at the beginning of this conversation, it
didn't parse as a mailhost.  Since then, you said that the account which
corresponds to that tracker has become mailhosted, and in fact, it
parses with the appearance of a mailhosted account.

But, even tho' it parses with the appearance of a mailhosted account
called 'gountchev' now, as opposed to before when the thread started,
the mailhosted account does not have the whacky btconnect server calling
itself hesl01uker.he.local in its Received traceline associated with the
gountchev account.  SC sez

<snip>
4: Received: from c2bthimr02.btconnect.com ([194.73.73.202]) by
hesl01uker.he.local with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr
2006 00:07:42 +0100
Hostname verified: c2bthimr02.btconnect.com

Possible forgery. Supposed receiving system not associated with any of
your mailhosts
Will not trust anything beyond this header
</snip>

Where 'supposed receiving system' being mentioned is hesl01uker.he.local

Perhaps the deputy manually configured the mailhost for some whacky name
or another that s/he saw, such as hesl02uker.he.local [there is such a
server as that] or some other -- or perhaps when there is a manual
configuration, things don't work the same as expected.

I'm just guessing that the mailhost configuring for the btconnect server
family is incomplete.


-- 
Mike Easter
kibitzer, not SC admin