My ISP now requires me to use SSL/TLS with user/pass authentication, when relaying mail though them. SSL/TLS is already supported by 1.06, but user/pass authentication is not.
The patch http://tomclegg.net/qmail/qmail-remote-auth.patch adds user/pass authentication, but contains a few conflicts when applied on top of netqmail-1.06 ebuild.
Attached a new ebuild and a working patch.
Patch is applied when "ssl" use flag is enabled.
Tested on x86 with USE="gencertdaily qmail-spp ssl -authcram -highvolume -vanilla"
Created attachment 280527 [details]
Created attachment 280529 [details]
Works for me on amd64. I put a netqmail under /usr/local/portage and set PORTAGE_OVERLAY in in /etc/make.conf, downloaded netqmail-1.06-r1 and the patch, regenerated the manifest and installed. I can now relay out to smtp.gmail.com no problem. Used the USE flags as Sonni described, also.
This really needs to get in upstream where possible.
tested patch and running netqmail-1.06 against google and a rather picky debian/exim setup.
Works as expected.
For reference, the following seems to be the most up-to-date collection of qmail patches wrt SMTP auth:
Their version of the implementation (qmail-authentication-0.8.1.tgz) would be interesting to implement, as it combines everything into one patchset - for better or worse.
This could replace the existing "qmail-spp-smtpauth-tls-20060105.diff" patch as well as the one from this bug.
Why is the status of this Enhancement Request UNCONFIRMED? The patch seems to work and is an important enhancement to netqmail more and more users will need.
When is the fix for SMTP AUTH supposed to appear in portage?
The previous patch does no longer work with netqmail-1.06-r2.
I took Tom Clegg's patch, re-applied it manually to the current version, made some simplifications (the while-loop before sending AUTH LOGIN does nothing useful IMHO) and bug fixes (e.g. the AUTH user in "MAIL FROM:" should be the same as specified in the AUTH LOGIN command), and generated a new patch (attached).
To be done: Instead of the while-loop mentioned above, it would be useful to check the actual AUTH methods supported by the server and then pick one of these to send the auth data. Furthermore, in the AUTH-Process, parameters may not necessarily be requested in the expected (hard-coded) sequence, so it might be useful to base64-decode the challenges and actually send the requested tokens.
However, the patch works for me (with netqmail-1.06-r2) with plain text parameters in control/smtproutes, and I'm interested in feedback as to how it works for others.
Created attachment 366400 [details, diff]
remote-auth patch for netqmail-1.06-r2
Tested against gmail and a rather picky debian/postfix setup =;)