Achim Grolms wrote: > Graham's point is - a change in behaviour will break existing code > that relies on Net::POP3 and that behaviour. > My point is: There is no "own fault". Remember John Postels "law": "be > conservative in what you do, be liberal in what you accept from others."
Sigh, I must repeat myself: I reckoned with that argument. ;) While I'd see this the other way around: accepting in this case is the list of capabilities (no SASL algorithms) and doing is what you try (sending out AUTH CRAM-MD5 without the server announcing support). And the other question is: what are standards are good for then? >> In contrast I've seen servers which >> disconnect if confronted with mechanisms they don't know. > > That's no problem if that servers announce the mechisms they support. Sure, but I meant such not that advertise SASL that crash or otherwise disconnect when receiving AUTH CRAM-MD5. > Do you know a POP3 server out there that matches this criterion? I've seen several of them in the last two years, but I didn't write down their names. What I can live with is asking the server the old way via "AUTH". Since this is implemented in 2.28_2 I really don't see a reason for || 'CRAM-MD5' anymore. > But as a programmer you always can use the capa() method to check > if the server announces SASL to avoid the CRAM-MD5 fallback. Yep, I tested this and it works. Unfortunatelly it results in two CAPA's sent out. Wouldn't it be better if in auth() $self->capabilities would be used? >> > The actual version in repository is available at >> > <http://svn.goingon.net/repos/libnet/trunk/Net/POP3.pm> >> > (hopefully becoming 2.29, I hope Graham will bring it to CPAN). >> >> I've looked into that version. While the current code is good readable, >> the changes in 2.28_2 are quite a mess for a Perl newbie like me. > > It was hard to write, it should be hard to read. > What part in detail is the problem? No special part. It's when statements get interleaved like my %user_mech; @[EMAIL PROTECTED] = (); or my @mech = @user_mech ? grep { exists $user_mech{$_} } @server_mech : @server_mech; And that not only one time here or there but several succeeding. But as I wrote, it must be me since I'm not trained to this. > 2. checks if one of that mechnisms match the supported mechanisms of the > clientside Authen::SASL object. > One of the the mechanisms of intersection of serverside and clientside > mechanisms is choosed and used for authentication. (Fail if intersection is > empty). The question is, how it fails. In 2.28_2 $sasl->client_new() survives instead croaking. Must have something to do with passing 'pop' instead of 'pop3' when calling from auth(), but I don't understand why. Anyways the result is the same I wanted to achieve, but I had to tweak Authen::SASL's client_new(). Jürgen
