tomas.juqutuseveh.lee.796265 at gmail
Jan 25, 2010, 2:07 AM
Post #4 of 6
(1550 views)
Permalink
|
|
re: Bug in many patches (incl. John Simpson's) to qmail-remote to handle SMTP AUTH
[In reply to]
|
|
On Jan 22, 2010, John Simpson <jms1 [at] jms1> wrote:
> On 2010-01-22, at 0008, Tomas Lee wrote:
>>
>> Many months ago, I tried to report a minor bug in John Simpson's
>> qmail-combined-patch. I tried subscribing to the mailing list,
>> but I never got my subscription approved, and I tried writing him
>> directly, but I never heard anything. So I gave up.
>
> "many months ago", meaning four days ago?
No, meaning "many months ago." August 19, to be precise. The
subscription request I sent on January 18 was not my first attempt. I
was first affected by this bug in the summer, and I recorded the bug and
my in my notes and tried to send a report upstream. I then forget about
it until I had occassion to install qmail on another system. When I
consulted my notes, I was reminded of this bug and decided to try to
report it again. It was just a coincidence that I saw your message to
the qmail mailing list (to which I was already subscribed) at this time.
> i manually approve all of the subscription requests, because spammers
> sometimes try to subscribe to the list. and to be honest, your email address
> looks like a random collection of words and numbers that a spammer would
> come up with, so i ignored it, thinking you were a spammer. this is the
> first time i'm aware of being wrong about guessing which addresses were
> spammers, you have my apologies for ignoring you.
That's OK. Don't worry about it. I hope I didn't sound like I'm
bearing a grudge or anything. I'm just a guy who keeps a log of all the
non-spam mail I send or receive. I'd actually forgotten about it until
I re-read my notes.
> now that i see you're a human being (and not a spammer, at least i hope not)
> i've just approved your subscription request. however i'm not sure ezmlm-idx
> will still consider it a valid request, i think it times them out after 72
> hours. if not, let me know and i'll add you by hand.
Yes, I've been subscribed.
> with that said...
>
> i will admit it's been a while since i looked at that part of the code, so
> i'm not as intimately familiar with it as i am with most of the patches
> affecting qmail-smtpd. i'd rather have somebody who's more familiar with
> that part of the code look at the issue first, and see if they can fix it.
> if so, then obviously i'll incorporate their fix into my combined patch.
>
> and if nobody else wants to look at it (or has the time) then i guess i can
> take a look, although any fixes i release will probably be specific to my
> patch, and people who use other patches will have to manually undo bits of
> my stuff and massage it into whatever patch they're using. i'd rather see
> the problem fixed in the "upstream" patches, than having to force others to
> have to figure out how to take a patch i wrote and figure out how to make it
> work with whatever patches they're using.
>
> i'll wait and see what others have to say before i start trying to dig into
> the code myself.
There is an upstream patch which xtext encodes the AUTH= parameter:
Erwin Hoffmann's AUTH patches, available at
<http://www.fehcom.de/qmail/auth/qmail-authentication-068_tgz.bin>,
linked from <http://www.fehcom.de/qmail/smtpauth.html>. But I gather
that, even though "the AUTH code in [your] combined patch is equivalent
to his qmail-authentication-0.6.4 patch" (with the exception of the
xtext encoding), that patch wouldn't actually apply cleanly to your
patch. So I understand why you'd want to wait and see what others have
to say.
Incidentally, you've already made changes in this area from the original
patch you used: you changed that AUTH= parameter from the envelope
sender to the authenticated user name. (I believe this is the correct
thing to do.)
The patch I used is pretty simple:
--- qmail-remote.c-the-old-source 2009-07-17 23:05:58.000000000 -0700
+++ qmail-remote.c 2009-07-17 23:03:53.000000000 -0700
@@ -531,9 +531,7 @@
if (authd) {
substdio_puts(&smtpto,"MAIL FROM:<");
substdio_put(&smtpto,sender.s,sender.len);
- substdio_puts(&smtpto,"> AUTH=<");
- substdio_put(&smtpto,auth_smtp_user.s,auth_smtp_user.len);
- substdio_puts(&smtpto,">\r\n");
+ substdio_puts(&smtpto,"> AUTH=<>\r\n");
substdio_flush(&smtpto);
} else {
substdio_puts(&smtpto,"MAIL FROM:<");
This has the advantage of being easy to understand, conforming to RFC
2554 (in fact, it's explicitly specified as conforming behavior), and
working for my particular situation. But I don't know enough to say
that this is the best thing to do for a widely distributed patch such as
yours. Some people who know more than I in this area (e.g., Erwin
Hoffman) encode other information in this paramter, and I can't argue
with them.
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.
|
PGP.sig
