Topic: New poll on SMTP authentication

[Dan York]

If you look on the main page for e-smith.org, you'll see there is a new poll asking if your ISP requires SMTP authentication before you can send outbound SMTP e-mail through their e-mail servers.

I posted this poll because I'm seeing anecdotal evidence that this practice is increasing among ISPs as part of their overall efforts to combat spam.  (The theory being that if a valid account name and password are required, someone just randomly connecting to a client network will not be able to send out huge volumes of spam.  It also allows them to more easily track at the ISP which messages are being sent out by which client. You can debate that theory, but it does seem that some ISPs, at least, believe it.)

Given that many ISPs are also increasingly restricting the use of servers on residential or less-expensive business connections, it means that more and more users will be forced to send their e-mail through the mail server of their ISP.

We currently allow you to specify your ISP's mail server via the "Internet provider's SMTP server" entry box on the "Other e-mail settings" web panel of the server manager.  However, we do not currently support SMTP authentication.  

I'm curious to know if your ISP does require the use of SMTP authentication before allowing you to send through their servers. If could take a moment to vote (once only, please!), I'd appreciate it.

Thanks,
Dan

P.S. Please note that we are NOT currently planning to add in SMTP authentication support... I am only gathering information to see how prevalent this practice is and whether or not we do need to address it in the future.  Thanks.

[Peter Schubert]

Hi Dan,

i only can tell you, that in Germany nearly every ISP need SMTP authentication (due the trouble of SPAM).

Peter

[Paul]

My ISP requires SMTP authentication and along with AOL and other rejecting emails from dynamic/non-business ip's it make the mail server just about un-usable for me.

SMTP authentication should be a major consideration for mitel.  JMHO.

[Scott Smith]

Dan -- You know my situation and I can confirm that this is an increasingly popular practice among ISPs. Prior to last summer, we'd seen this maybe a half dozen times. Since then, we've gotten over 100 requests for this capability.

Commentary -- The problem is the qmail license and the Mitel decision to not include a development environment. The qmail license prohibits the distribution of modified source or binaries. Patches are okay, but patches require a development environment to compile. Mitel rightly views putting a development environment onto the SME server to be insecure and unnecessary.

There is an SMTP AUTH LOGIN patch for qmail. You can download it and apply it and make the few minor configuration changes it requires. If you had a development environment. Which you can also download and install.

I can confirm that this patch works quite well.

Qmail's author does state that he will make exceptions to the licensing agreement, which means Mitel might gain permission to distribute a binary with the patch already applied. Might. From what I've read, it seems unlikely that DJB would approve such a distribution. But, there's always hope.

Bottom line: Mitel is unlikely to be the source of this solution, at least not so long as they stick with qmail. What is needed is a how-to on applying the patch and making the configuration changes.

[Jáder Marasca]

I´m a complete NEWBIE (on linux and on programming!) but...
 why couldn´t YOU Scott to distribute YOUR version of QMAIL PATCH (already compiled) ? And you know it works... so just copy one file to my server and this will work as desired!

What is wrong with my toughts ?
(AND DEFINATELLY THERE IS SOMETHING WRONG ... someone else already must had think about this...)

Thanks by your patience!

Jáder

[Bill Talcott]

Jáder Marasca wrote:
>
> I´m a complete NEWBIE (on linux and on programming!) but...
>  why couldn´t YOU Scott to distribute YOUR version of QMAIL
> PATCH (already compiled) ? And you know it works... so just
> copy one file to my server and this will work as desired!
>
> What is wrong with my toughts ?
> (AND DEFINATELLY THERE IS SOMETHING WRONG ... someone else
> already must had think about this...)

I'm a relative newbie also, but the way I understand it, a patch is more like a macro for changing the source code. You recompile the program with the specified patch file, and this makes the designated changes to the program. As Scott stated, you aren't allowed to distribute the modified version. At this point, you *must* recompile it yourself, although you could use a pre-made patch file to actually make the needed changes. But SME's target audience isn't really the recompiling type...

[Jáder Marasca]

OK! I got it... you cannot send to anyone your patched file...

[Cyrus Bharda]

Bill,

I am sure that if a HowTo was written so that it is easly followed then most people who want this feature would follow it. Those who recompiling would be too much for probably would want this feature anyway.

So Scott, how about writing a HowTo so that others might follow in your footsteps?

Thanks,

Cyrus Bharda

[Jáder Marasca]

Everyone could easily install a new SME (20 minutes) on a spare HDD (any 1Gb HDD!) and follow a HowTo and have HIS OWN copy of PATCHED QMAIL...

Speak freely...  DJ is lacking of common sense... Qmail is a WONDERFUL program... but not allow to distribute BINARY versions... is POOR MINDED behaviour!

If I had a PATCHED version (or WHEN I had it) I´ll let ANYONE who want it to have it!

I don´t think this will drive DJ CRAZY or UNHAPPY... neither will do his program to be less than it really is... A WONDERFUL PIECE OF CODE!

Just as most american say: JUST MY 2c!!

[Scott Smith]

DJB is quite right-minded if you consider that he makes a few claims about qmail, probably the two most important being security and performance. If Dan were to allow patched versions to be distributed -- which effectively hides the fact that the original source was patched -- then any security or performance issues that might arise from the patch would be (incorrectly) attributed to qmail itself.

Distributing the patched binary (it is only qmail-remote that affected) would violate the license agreement.

I cannot directly give you the tools I use to accomplish SMTP AUTH LOGIN due to confidentiality restrictions placed upon me by my employer. In other words, I cannot give you the templates and action scripts. However, I can give you a mini how-to explaining the steps, and from there this community can develop a more robust solution.

1. Install or obtain a development environment

2. Obtain the patch:  qmail-smtp-auth-send-0.0.1.tar.gz

3. Compile the patch.

4. Build a template to manage the /var/qmail/smtproutes_users file.

That's the very nutshell version.

And someone should take a look at xdelta-1.1.3-5.i386.rpm, which is a (hint) binary patching tool.

[Jáder Marasca]

> DJB is quite right-minded if you consider that he makes a few
> claims about qmail, probably the two most important being
> security and performance. If Dan were to allow patched
> versions to be distributed -- which effectively hides the
> fact that the original source was patched -- then any
> security or performance issues that might arise from the
> patch would be (incorrectly) attributed to qmail itself.

OK! I got the point... You (and Dan) are totally right! Accept my apologies!

(snip)
> 1. Install or obtain a development environment
> 2. Obtain the patch:  qmail-smtp-auth-send-0.0.1.tar.gz
> 3. Compile the patch.
> 4. Build a template to manage the /var/qmail/smtproutes_users
> file.
I´m a complete NEWBIE on linux , so please help me a little more:
Item 1, 2)   shouldn´t be a problem... contribs.org & google search will do it!
Item 3) Any different thing than ENTER ENTER ENTER (windows style of install!) or simple answers?
Item 4) I have no idea about what you´re talking about (I suppose that qmail auth patch must change a file and because SME use templates you´re telling me to do this...

One last question... Once I have done this by myself... could I install my patched version of QMAIL on each server I install or should I install all environment and rebuild qmail patch again to agree the license?

Thanks!

And again... accept my appoligies... I was blind and couldn´t see a so obvious point!

Jáder

[Scott Smith]

No problem. Personally, I think Dan needs to get on the stick and add features to qmail. The world has changed since version 1.03 was released. Or, Mitel needs to get on the stick and switch to another mail system.

You'll find complete instructions for compiling in the qmail-smtp-auth-send package. Of course, they assume you know some basics. If you're expecting a Windows point, click, enter type of install -- you will be disappointed.

smtproutes_users -- The explanation in the patch docs is sketchy. Basically, you are building a file of senders and their login credentials.

# address:mailserver[:port]|username|password
#
# examples:
#   mail@example.com:smtp.example.com|example.com1|examplePasswd
#   info@example.com:smtp.example.com|example.com2|anotherPasswd
#   anotherport@example.com:smtp.example.com:26|example.com3|justfoobar
#
# catch-all:
#   :smtp.example.com|everyone|somepwd

Taking the first example, sender "mail@example.com", relaying through "smtp.example.com", logs in with username "example.com1" and password "examplePasswd".

So, your task in the templates is to track every valid sender and build a line in the smtproutes_users file. Not difficult, but not trivial.

The last entry, the catch-all, I've never tried. From the patch docs, there seems to be some question as to whether it works or not. But the intent is for any sender relaying through "smtp.example.com" will login with the username "everyone" and the password "somepwd".

For my purposes, I have to use the former method. My (highly modified) SME configuration can use multiple SMTP relays.

For the typical SME configuration, I would think the catch-all method would be appropriate. Most sites relay through one smarthost (ISP mail server) and therefore don't need to route by sender with individual credentials.

Can you distribute the patched qmail? That depends. Are your systems for you own use, such as for an organization with multiple sites, etc? Then yes. Otherwise, probably not. If what you are doing could in any way be construed as "distributing" for anything other than your own personal or organizational use, then my understanding of the qmail license is that you may not distribute the modified binary.

However, is a patch to a binary the same as distributing a modified binary? If you distribute a source code patch that results in a modified binary, is that really any different? Honestly, I don't have a definitive answer. But, I do suggest you look at xdelta...

[Cyrus Bharda]

Scott,

> 1. Install or obtain a development environment
>

Well I know how to do that.

> 2. Obtain the patch: qmail-smtp-auth-send-0.0.1.tar.gz
>

As Jader said a quick search in Google will fix that

> 3. Compile the patch.
>

As Jader said, I am a noob too and do not understand what is involved in this step, can you or someone who knows how to complie this patch please futher explain?

> 4. Build a template to manage the /var/qmail/smtproutes_users file.
>

Templates I am very much aware of and know how to manage them, so this step is fine.

> That's the very nutshell version.
>
> And someone should take a look at xdelta-1.1.3-5.i386.rpm, which is a (hint) > > binary patching tool.

Thanks Scott for that basic rundown, is there instructions somewhere on compiling files on SME? I did a search and pulled up these but didnt really understand them:

http://forums.contribs.org/index.php?topic=15930.msg61475#msg61475
http://forums.contribs.org/index.php?topic=15930.msg61475#msg61475
http://forums.contribs.org/index.php?topic=15930.msg61475#msg61475

Thanks,

Cyrus Bharda

[Scott Smith]

I'd suggest tapping one of the others on this list for compiling help. I know enough to work through it, but it is not my area of expertise.

Darrell has put together the necessary packages for loading the compiler. Others can probably help with the specifics of doing the compile IF THE INSTRUCTIONS IN THE PATCH ARE UNCLEAR OR DO NOT WORK.

Oh, IIRC, I did miss one step. (I did all of this about a year ago, and I'm passing this along from memory -- hence the lack of detail.) You'll also need to obtain and load the qmail source (see qmail.org) before you can recompile the patch.

As I recall, the loading of the compiler, qmail source, and patch, and then running the make itself, was not all that difficult. Just load the development RPMs, follow the qmail.org instructions for loading the qmail source, and follow the patch instructions for loading the patch and doing the make.

When you are finished, it is only the qmail-remote binary that will be modified, and all related configuration is in the smtproutes_users file, so it is a pretty clean modification. I keep a copy of both the original and patched qmail-remote files (named qmail-remote.std and qmail-remote.auth) on my systems, and my configuration program determines which one to copy to qmail-remote, and also sets configuration database settings to control my smtproutes_users template. (As I said, I can't give you my -- my company's -- template, and even if I did it is far too complex for the typical SME install.)

I'd recommend putting two additional properties on the qmail key:

/sbin/e-smith/db configuration setprop qmail authuser=xxx authpass=xxx

Then, in your template script, only select SMTP AUTH LOGIN if both authuser and authpass are defined (having only one makes no sense.) Doing it this way you don't need a separate SMTP AUTH LOGIN enabled flag. However, if you feel more secure with a specific flag:

/sbin/e-smith/db configuration setprop qmail authlogin=enabled

If you prefer not to modify the existing 'qmail' key, create:

/sbin/e-smith/db configuration set SMTPAuthLogin custom status enabled username xxx password xxx

Either way, same effect, but sometimes dealing with an existing key is easier when doing templates.

Ah, yes, the reason for keeping copies of both patched and unpatched qmail-remote. The patched qmail-remote will produce unwanted log messages if SMTP AUTH LOGIN is not being used and is not configured. Keeping the original around lets me keep the logs cleaner.

[Cyrus Bharda]

Scott,

God damn, all of that went straight over my head anyway I think I'll just make do with what we have, I really do not have the time to fiddle and fart around and do all that compiling work, it just wont be worth my time to, but thanks anyways .  Hopefully sometime in the future someone will make a step by step, look here and type this type howto for noobs like me, until then I will be happy to wait , thanks for your help though!

Cyrus Bharda