SpamCop.net changed thier logon again...
Status: Abandoned
Brought to you by:
toniw
Menu
▾
▴
Logged In: YES
user_id=1074375
It works like a charm, also for registered users:
Registered users should use their login as ID.
Regards,
Ruud
Logged In: YES
user_id=682175
How would someone on a windows platform apply this diff to
update the script? Perhaps someone can upload the patched
version to sourceforge with a version update?
Logged In: NO
I can't get the patch to apply cleanly:
amorton@multivac:~/bin> patch spamcup.pl spamcup.diff
Hmm... Looks like a new-style context diff to me...
The text leading up to this was:
--------------------------
|*** /usr/local/bin/spamcup.20040713.pl 2004-07-14
02:17:15.000000000 +0200
|--- /usr/local/bin/spamcup.pl 2004-07-14
02:23:26.000000000 +0200
--------------------------
Patching file spamcup.pl using Plan A...
Hunk #1 succeeded at 95.
Hunk #2 succeeded at 106 with fuzz 2.
Hunk #3 failed at 125.
Hunk #4 succeeded at 166 with fuzz 1.
Hunk #5 failed at 208.
Hunk #6 succeeded at 218.
2 out of 6 hunks failed--saving rejects to spamcup.pl.rej
done
Could somone give me a hint or two on how to get it working?
Logged In: YES
user_id=682175
Perhaps someone can be so kind as to upload the patched
version and bump up he version number?
Logged In: YES
user_id=190645
Molensky, could you resubmit the patch in "diff -u" format.
Also add an entry to the ChangeLog describing what
feature(s) has been added. The version number can be also
increased to 1.08.
It's nice to get patches from users of Spamcup too, thank you!
Logged In: YES
user_id=1028193
I submit two new files. The first is a diff-file in -u format. The
second is a complete spamcup.pl-file for those, with trouble
patching.
I read that for UNPAID users of spamcop the 'code' option still
functions, so they should not use this script. I will make a
next change to the code to also allow for both the 'code'
as 'login/pwd'. Than I will increase the version to 1.08. And
append some explaination to the changelog.
I hope to upload 1.08 some time tomorrow. Today my boss
claims my time, but tomorrow it's weekend...
Logged In: YES
user_id=190645
Great.
As you will be providing an enhanced version of this patch
later, I won't commit this.
Just to clarify: this patch works only for people who has a
paid account on Spamcop.net. The others (free users without
username/password) should not try to use this patch as it
doesn't work for you.
Logged In: YES
user_id=1028193
I uploaded three new files and removed the older files. Version
number is increased to 1.08. Uploaded files are the changelog,
a finished .pl-file and a diff-file. The patch is relative to the
1.07 release.
I haven't got the change to live-test the backwards
functionality for UNpaid users of SpamCop. But it should work.
Can someone confirm the correct function for those users?
ChangeLog 1.08
spamcup.1.08.pl
Diff-file in -u format
Logged In: YES
user_id=229489
Is anyone else having a problem with the new SC's new logon
method? I can logon with a web browser using cookies but not
using HTTP Auth (and therefore I can't use Spamcup).
I'm posting a message asking about it on SpamCop's board too
but I wasn't sure if this was something someone had already
seen.
Logged In: YES
user_id=1028193
What kind of error/page do you see? If you use cookie's, you
can login through the www.spamcop.net-url, but for HTTP
Auth, you should use MEMBERS.spamcop.net.
Do you have a link to the message-board article?
Logged In: YES
user_id=229489
Sorry, I ended up getting distracted. Here's the link
http://forum.spamcop.net/forums/index.php?showtopic=2135&view=findpost&p=13548
www.spamcop.net with the cookie login works just fine as
does the webmail (using the same logon info). Trying to log
into members.spamcop.net doesn't work.
Logged In: YES
user_id=1028193
drewish, I saw at the forum some posts, but not if it is solved
or still not functioning. As it is also not working from a normal
web-interface, I think you should focus on there.
In the mean time, I will try to register a new account at
spamcop this weekend and test the 'code' option for
backwards compatibillity. If this is successfull, toniw can
commit the code and close this bug/patch.
If you succeed in successfully authenticating using HTTP
Auth in a normal browser, you can open a new bug-ID. (Any
comments on this practise toniw?)
But to help you further along, have you tried to login using
the -c option of spamcup? Enter 'spamcup.pl -c
RaND0mSTrinG' or browse to http://www.spamcop.net/?
code=RaND0mSTrinG. Can you report UCE with this method
(either spamcup or web-interface)?
Logged In: YES
user_id=229489
i've found that i can log into the mailsc.spamcop.net using
the url drewish%40spamcop.net:password@mailsc.spamcop.net
but not to members.spamcop.net. i've tried using that url
with spamcup but it didn't work. i'm assuming that the
members.spamcop.net did some redirect that the script relys
on. is that assumption correct?
Logged In: YES
user_id=1028193
UPDATE: Seems like spamcop only allows new registrations
using username/password. So I am unable to verify whether
this version is backwards compatible. If it is not... register for
using login/password instead of the ?code=afJKHdsf option ;)
Drewish, as far as I know, the creditials for MAILSC and
MEMBERS are NOT the same. Have you tried using an other e-
address (like the one you originally signed up with or your final
destination address)? If this doesn't help, I suggest you have
your password resend to you
(http://www.spamcop.net/denied.shtml) or contact a deputy
through deputies <at> admin.spamcop.net or service <at>
admin.spamcop.net
Shall we continue this discussion at the forum at
spamcop.net? If you have any more information which could
help in solving your problem, please post it there. Can you
please post there which OS etc. you are using to browse to
members.spamcop.net?
Logged In: YES
user_id=229489
I finally got around to pokeing at the script trying to get
it working and figured out a few things but it's not
working yet. I was hoping someone could explain a few parts
of the script.
If I replace members.spamcop.net with mailsc.spamcop.net in
the URLs I can log in and find the first ID. Trying to grab
that fails because there's no username or password. The
offending line looks like:
$res = LWP::UserAgent->new->request( $form->click() ); #
click default button, submit
What I'm curious about is why the original UserAgent $ua is
unset and a new one created everytime. It would seem easier
to make sense to set $ua->credentials($netloc, $realm,
$uname, $pass) up top and just keep using that. Am I missing
something? Does this just reflect the authentication-less
history of Spamcup?
I'm going to try setting the credentials and see if I can
get that working. I'll report back.
Logged In: YES
user_id=229489
Well I got it working by connecting using:
$host = 'mailsc.spamcop.net';
$ua->credentials($host . ':80', 'your SpamCop account',
$SCident, $SCpass);
$req = HTTP::Request->new(GET => 'http://' . $host);
and then submitting with:
$req = HTTP::Request->new( $form->click() );
$res = $ua->request( $form->click() ); # click default
button, submit
I'll post a patch but I wast to find out one thing first.
Once you've logged (using either
"user:pass@members.spamcop.net" or "www.spamcop.net/?code="
) you fetch spam reports from "www.spamcop.net/sc?id=". This
is in contrast to logging into "mailsc.spamcop.net" and
fetching reports from "mailsc.spamcop.net/sc?id=". Correct?
Logged In: YES
user_id=1028193
Fetching a parsed spam to report, does not require you to
login. You only have to login to fetch a ID for the next one in
line. I don't know how it works for mailsc-users. But after you
login using members.spamcop.net, and retrieved the next ID,
you can use either www.spamcop.net/sc?id= or
members.spamcop.net/sc?id=
I haven't found any differences in sending the reports using
either of those domains. Only in the web-interface are some
differences. All preferences for sending are still being used by
SC.
I would suggest: try changing all occurences of
*.spamcop.net with $SChost
Logged In: YES
user_id=229489
In the process of cleaning up my changes I got to wondering
if there was any reason to continue to support the code= login.
Molensky, you mentioned that you'd read that it was still
supported. Do you remember where? It seems like they're
trying to push everyone toward the password logons.
Logged In: YES
user_id=229489
Based on this:
http://www.spamcop.net/mcgi?action=loginform
It looks like paid users should be using mailsc and free
reporting users should be using members. Does this
contradict anything else you've seen?
I went ahead and wacked the code logon. I removed some of
the options and added a -m one to select paid accounts.
Thinking about it now I guess it would have been just as
easy to check for @{cesmail,spamcop}.net and set the host
accordingly. Oh well.
I tried to clean up some of the indenting but made it worse
so I just ran it through perldtidy. The down side is that at
this point a patch would probably be bigger than the so I'm
just going to attach my version.
Logged In: YES
user_id=1028193
The reason for still supporting the code= option, is because
SC does. At there front site:
"Free users will be encouraged to establish a password ...
After some time, the existing (old) URL authentication scheme
will be disabled and all users will be forced to establish a
password." Until SC forces their users to establish a
password, it's a simple effort to make it work both ways.
For as far as hostnames goes and types of users, in my opion
there are THREE types of users: the first are the unpaid users
(no fuel, with nag-screen), then paid users (with fuel and no
nag-screen). Both can only report. Using www. or members.
is trivial (except for type of authentication). The last are the
email-account-users, which should be using mailsc. I don't
know if those users could also use www. or members. but as
the systems for mail-account-holders is different for the
reporting-only, I suspect not.
If you upload your patch, I will test it.
PS. use diff with the options -E -b to ignore white spaces.
You have a tidy-ed version for programming/debugging. And
the patch-file still remains small.