HELP!
Under up-to-date Fedora distribution, I tried the command
patch popfile.pl popfile-0.21.0-apop.patch
in the popfile source directory. Can someone tell me why
this did not work? and what to do instead?
Many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me add a support comment trying to push APOP support
strongly.
As always, I heard from many Japanese users praise to
POPFile 0.21.0 for its again high quality and performance
improvement. However, I have also heard disappointment
about APOP support missed in 0.21.0.
It looks like APOP is mandatory for many Japanese educational
institution or corporate use and many users is giving up using
POPFile just because it does not support APOP.
Junya
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will make a few small changes (eg, storing the entire banner
in a protocol-independent way in Proxy.pm, and letting
POP3.pm parse for the <foo> part) and check this in.
Is there any other way to do this than creating the :apop
extension to POPFile's USER syntax?
Since the password is being sent to POPFile in the clear
anyhow, what would you think of using a modified APOP
command?
eg, APOP username:password HASH
This would require POPFile to send an APOP-compliant banner
(there are a few parameters we could use to ensure that it is
unique), and this would pave the way for Multi-user phase II
to use APOP to authenticate directly with POPFile.
Regards,
Sam
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, finding a working APOP implementation out on the
internet to test against was hard. None of my POP3 servers
support it.
It turns out a LOT of mail servers indicate that they support
APOP by including <> in their banner, but they don't seem to
work at all. At first I thought the perl code (somehow) was to
blame, but then I tried with two or three other clients and got
the same result.
And I was looking forward to using APOP on my accounts that
seemed to support it.
Anyways, I have made a few more modifications (eg,
detecting whether the banner sent by a mail server is an
APOP-capable banner) and brought variables up to POPFile's
coding guide. Excellent patch, though.
I have this ready to check in once I make tests and John
unlocks for non-critical fixes.
Regards,
Sam
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are the files I will be checking in for APOP support once I
complete tests incase anyone wants to drop them ontop of
their 0.21.0 or 0.21.1 installs to get APOP support right now.
Regards,
Sam
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I am chasing that one down. It was causing some test
failures.
The "easy fix" of adding an if to the error-generating
statement prevents the error from printing, but it also
prevents other messages from making it through (oddly) when
there is a transaction level error (Eg, wrong password).
get_response has some optional parameters, one of which
can be used to supress any printing to the client (rather than
leaving the client socket undefined). I didn't catch it on the
first read through, but with the call used correctly, this error
doesn't occur.
Anyways, one or two more glitches to iron out while finishing
the test suite, then I will commit my changes and repost the
files.
Regards,
Sam
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
APOP patch to 0.21.0
Logged In: YES
user_id=578491
Sam,
Can you take a look at this?
John.
Logged In: YES
user_id=640073
Roger. Added it to my local "todo" diary.
Regards,
Sam
Logged In: YES
user_id=895926
HELP!
Under up-to-date Fedora distribution, I tried the command
patch popfile.pl popfile-0.21.0-apop.patch
in the popfile source directory. Can someone tell me why
this did not work? and what to do instead?
Many thanks.
Logged In: YES
user_id=895926
Never mind. I withdraw previous comment, and I did not
notice the version 0.21.0 replacing 0.20.1. duh
Logged In: YES
user_id=723403
Let me add a support comment trying to push APOP support
strongly.
As always, I heard from many Japanese users praise to
POPFile 0.21.0 for its again high quality and performance
improvement. However, I have also heard disappointment
about APOP support missed in 0.21.0.
It looks like APOP is mandatory for many Japanese educational
institution or corporate use and many users is giving up using
POPFile just because it does not support APOP.
Junya
Logged In: YES
user_id=640073
Ok, looks nice.
I will make a few small changes (eg, storing the entire banner
in a protocol-independent way in Proxy.pm, and letting
POP3.pm parse for the <foo> part) and check this in.
Is there any other way to do this than creating the :apop
extension to POPFile's USER syntax?
Since the password is being sent to POPFile in the clear
anyhow, what would you think of using a modified APOP
command?
eg, APOP username:password HASH
This would require POPFile to send an APOP-compliant banner
(there are a few parameters we could use to ensure that it is
unique), and this would pave the way for Multi-user phase II
to use APOP to authenticate directly with POPFile.
Regards,
Sam
Logged In: YES
user_id=640073
Wow, finding a working APOP implementation out on the
internet to test against was hard. None of my POP3 servers
support it.
It turns out a LOT of mail servers indicate that they support
APOP by including <> in their banner, but they don't seem to
work at all. At first I thought the perl code (somehow) was to
blame, but then I tried with two or three other clients and got
the same result.
And I was looking forward to using APOP on my accounts that
seemed to support it.
Anyways, I have made a few more modifications (eg,
detecting whether the banner sent by a mail server is an
APOP-capable banner) and brought variables up to POPFile's
coding guide. Excellent patch, though.
I have this ready to check in once I make tests and John
unlocks for non-critical fixes.
Regards,
Sam
APOP supporting POP3.pm
Logged In: YES
user_id=640073
Here are the files I will be checking in for APOP support once I
complete tests incase anyone wants to drop them ontop of
their 0.21.0 or 0.21.1 installs to get APOP support right now.
Regards,
Sam
APOP supporting Proxy.pm
Logged In: YES
user_id=723403
I got the error message below. If I comment out
Line 453:
print $socket $text; # don't print if $socket undef
and replace with
print $socket $text if defined $socket && $socket-
>connected; # don't print if $socket undef
everything seems work.
2004/4/7 16:54:53 1740: pop3: 243: auth APOP
2004/4/7 16:54:53 1740: pop3: 452: +OK hello test
2004/4/7 16:54:53 1740: pop3: 208: Command: --pass
XXXXXX--
2004/4/7 16:54:53 1740: pop3: 286:
digest='5ac3e6cb2983d51d351b3a126c26eb20'
2004/4/7 16:54:53 1740: pop3: 452: APOP test
5ac3e6cb2983d51d351b3a126c26eb20
2004/4/7 16:54:53 1740: pop3: 452: +OK test has 2
messages (990 octets).
Can't use an undefined value as a symbol reference at
c:\progra~1\popfile/Proxy/
Proxy.pm line 453, <GEN2> line 2.
Logged In: YES
user_id=640073
Yes, I am chasing that one down. It was causing some test
failures.
The "easy fix" of adding an if to the error-generating
statement prevents the error from printing, but it also
prevents other messages from making it through (oddly) when
there is a transaction level error (Eg, wrong password).
get_response has some optional parameters, one of which
can be used to supress any printing to the client (rather than
leaving the client socket undefined). I didn't catch it on the
first read through, but with the call used correctly, this error
doesn't occur.
Anyways, one or two more glitches to iron out while finishing
the test suite, then I will commit my changes and repost the
files.
Regards,
Sam
Proxy.pm with fixes mentioned in april
Proxy.pm with CVS fixes mentioned april 8
POP3.pm with CVS fixes mentioned april 8
Logged In: YES
user_id=640073
I have uploaded POP3.pm and Proxy.pm files that match the
final CVS commit I did for this issue on April 08. Sorry I didn't
upload these earlier.
If you have been having trouble using the files attached to
this patch tracker item, I apologize. Please try the most
recent attachments.
Regards,
Sam
version without HTML junk from IE
version without HTML junk from IE
Logged In: YES
user_id=640073
Another woops. Looks like I didn't spot the conversion of <
and > into >'s and <'s.
The most recent two files should be 0.21.0 compatible.
Regards,
Sam
really clean file
really clean file