Mailing List Archive: Qmail: users

Bug in Erwin Hoffmann's qmail-authentication-068_tgz.bin's xtext function (was: Bug in many patches (incl. John Simpson's) to qmail-remote to handle SMTP AUTH)

Index | Next | Previous | View Threaded

tomas.juqutuseveh.lee.796265 at gmail

Jan 26, 2010, 5:24 PM

Post #1 of 2 (993 views)
Permalink

Bug in Erwin Hoffmann's qmail-authentication-068_tgz.bin's xtext function (was: Bug in many patches (incl. John Simpson's) to qmail-remote to handle SMTP AUTH)

On Jan 25, 2010, Tomas Lee <tomas.juqutuseveh.lee.796265 [at] gmail> wrote:
> To be more generally correct, I would have had to copy the xtext
> encoding function from qmail-authentication-068_tgz.bin (about two dozen
> lines of code.)
>
> Hmm... Now that I'm looking at qmail-authentication-068_tgz.bin, the
> xtext encoding function doesn't look completely correct either. I had
> tested it before, but I only looked to make sure it was syntactially
> correct (i.e., no unencoded "=" or "+" signs). I didn't check to see if
> it decoded to the same value. But maybe I'm just thinking that because
> it's late. I'll see if I can find time later to set up scratch
> installation and test this.

It wasn't the late hour. There really is a bug in the xtext encoding function.

The relevant lines in the patch are:

if (s[i] == '+') {
if (!stralloc_cats(sa,"+3D")) temp_nomem();
} else if (s[i] == '=') {
if (!stralloc_cats(sa,"+2B")) temp_nomem();

That's backwards. '+' should encode to '+2B', and '=' should encode
to '+3D'. As it is now, '+' and '=' get encoded as each other.

I'll report this to Erwin Hoffman. Actually, I think he's on this list,
so I'll just change the subject of this message and hope he notices it.

feh at fehcom

Feb 2, 2010, 2:57 PM

Post #2 of 2 (819 views)
Permalink

Re: Bug in Erwin Hoffmann's qmail-authentication-068_tgz.bin's xtext function (was: Bug in many patches (incl. John Simpson's) to qmail-remote to handle SMTP AUTH) [In reply to]

Hi,

thanks for the Bug report. It was a simple mistake in the if-clause (too
bad, but not severe).

I've upated my patched version of qmail and provided some (more) insights
regarding SMTP authentication and the consquences for (E)SMTP traffic:

<http://www.fehcom.de/qmail/smtpauth.html>

regards.
--eh.

BTW: This will be part of SPAMCONTROL 2.6x - hopefully coming soon.

--On Tuesday, January 26, 2010 17:24:00 -0800 Tomas Lee
<tomas.juqutuseveh.lee.796265 [at] gmail> wrote:

> On Jan 25, 2010, Tomas Lee <tomas.juqutuseveh.lee.796265 [at] gmail> wrote:
>> To be more generally correct, I would have had to copy the xtext
>> encoding function from qmail-authentication-068_tgz.bin (about two dozen
>> lines of code.)
>>
>> Hmm... Now that I'm looking at qmail-authentication-068_tgz.bin, the
>> xtext encoding function doesn't look completely correct either. I had
>> tested it before, but I only looked to make sure it was syntactially
>> correct (i.e., no unencoded "=" or "+" signs). I didn't check to see if
>> it decoded to the same value. But maybe I'm just thinking that because
>> it's late. I'll see if I can find time later to set up scratch
>> installation and test this.
>
> It wasn't the late hour. There really is a bug in the xtext encoding
> function.
>
> The relevant lines in the patch are:
>
> if (s[i] == '+') {
> if (!stralloc_cats(sa,"+3D")) temp_nomem();
> } else if (s[i] == '=') {
> if (!stralloc_cats(sa,"+2B")) temp_nomem();
>
> That's backwards. '+' should encode to '+2B', and '=' should encode
> to '+3D'. As it is now, '+' and '=' get encoded as each other.
>
> I'll report this to Erwin Hoffman. Actually, I think he's on this list,
> so I'll just change the subject of this message and hope he notices it.
>

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads