Hi Michael,
On Sun, 24 Dec 2006 12:03:04 -0500 "Michael C. Toren" <[EMAIL PROTECTED]>
wrote:
> I recently transitioned mail.netisland.net from 0.28-tcpserver to
> 0.32-forkserver, and in doing so ended up making a number of small
> changes. The attached diff does the following:
>
> o lib/Qpsmtpd/SMTP.pm
>
> - The code in fault() which displays error messages looks like
> it wanted to prefix the message with the name of the process
> and its PID, however the "$0[$$]" expression was being
> parsed as an array lookup on @0. I also modified the
> expression to only display the first word of $0, as in many
> cases $0 has been modified to include information
> identifying the current SMTP conversation.
ok, commited with a small change ($name,"[$$] ..." to make this really
unambigous
> - Treat DENY_DISCONNECT from connect hooks the same as DENY.
> Previously, a return code of DENY_DISCONNECT was being
> ignored, resulting in the default DECLINED action being
> taken.
added with the same for DENYSOFT_DISCONNECT
> - Rather than always blindly appending " ESMTP" to the
> smtpgreeting, only append when the smtpgreeting does not
> already contain the word ESMTP.
ok
> - Make the space after "mail from:" once again be optional,
hm, this worked for me...
> initialize $from_parameter to "" in order to avoid "Use of
> uninitialized value" warnings.
>
> - In RCPT TO, perform more careful error checking on the
> object returned by Qpsmtpd::Address->parse. Previously,
> "RCPT TO:<mct>" resulted in SMTP.pm not realizing that the
> address was not properly parsed, and passing the plugins a
> Qpsmtpd::Address object where both the user and host were
> undef.
...both skipped for later revision
> - The HELP command previously never returning a response
> to the client due to missing parenthesis in the ternary
> operation used to construct the response string.
already fixed in svn.
> Matt pointed out to me in the #qpsmtpd IRC channel that this is a
> patch against the 0.32 distribution rather than the 0.3x SVN branch,
> but as all of these changes are about three lines or less, hopefully
> they won't present much of a problem when applying. If that turns out
> not to be true, please let me know, and I'll be happy to put in the
> grunt work to produce another diff.
Hmm, both files failed to apply with all hunks, some of them probably
because of the 20 line context. Please redo the -forkserver patch.
Hanno
