qmail and sasl

Hi folks,

i am faced with the task to deploy a single sign on authentication
engine. For now we have openldap, kerberos working 100%.
I know qmail supports ldap.
My users' userPassword attribute are currently setted for {SASL}xxxx <at> my.domain.
I wonder if qmail (even with ldap support) supports the SASL
authentication "method".
If not, is anybody aware about someone's patch that implement it ?

Thanks in advance.

Best regards,

Friedrich.

Re: qmail and sasl

Hi Friedrich 

(oh we share the same name ..),

On Wed, 6 Jul 2011 15:58:43 -0300
Friedrich Locke <friedrich.locke <at> gmail.com> wrote:

> Hi folks,
> 
> i am faced with the task to deploy a single sign on authentication
> engine. For now we have openldap, kerberos working 100%.

Ok.

> I know qmail supports ldap.

With Andree Oppermann's patch.

> My users' userPassword attribute are currently setted for {SASL}xxxx <at> my.domain.
> I wonder if qmail (even with ldap support) supports the SASL
> authentication "method".

What do you want to achieve ?

SASL is a library (and I doubt - except vor Inter7 - anyone is willing to marry it with qmail) -- and a framework.
However, SASL allows different authentication schemes, which may include the 'PAM' method (as 'external
SASL' method).

> If not, is anybody aware about someone's patch that implement it ?

Re: qmail and sasl

Hi Friedrich,

On Wed, 6 Jul 2011 17:36:54 -0300
Friedrich Locke <friedrich.locke <at> gmail.com> wrote:

> >
> >> If not, is anybody aware about someone's patch that implement it ?
> >
> > Tell us about your plans, what is your problem.
> 
> My plan is to make qmail authenticate users whose entries'
> userPassword is set to be forwarded to SASL.

Thus your 'User DB' is either in the LDAP or Kerberos Realm ?
(Check for my SMTP Authentication tutorial).

With LDAP authentication, this should be possible; either for simple or strong bind.
This is the typical case, even if Kerberos is used else.

In fact, check for the following:

a) qmail-smtpd uses (by means of the PAM) an extensible authentication scheme.
b) You need a particular PAM to connect to the LDAP DB, binding, and exiting on success with RC=0.
c) Address mangling (Kerberos realm, DN etc), should not be to difficult (the target domain can be used as a hint).
d) A good starting point is my qmail-ldap PAM (in PERL) for user validation (not authentication). 

regards.
--eh.

--

-- 

broken smpt-auth

Re: broken smpt-auth

ANNOUNCE - SURBL filter for netqmail

"connection died" errors and Postini - patch

Not long ago we noticed on our outbound mail servers that a surprising
number of qmail-remote processes were living a much longer than expected
life before throwing a "connected to <foo> but connection died" error
and deferring the message.  We were able to tie these down to processes
communicating with Google Postini and catch an strace that showed a
surprising bug with Google's mail server.  After receiving the DATA
Google intends to reject the message with a 571 code, but sends this:

read(3, "571 Message Refused\r", 128)

Unfortunately the message really needs to have both a CR and LF at the
end (\r\n) according to RFC 821 (section 4.1.2):  "The argument field
consists of a variable length character string ending with the character
sequence <CRLF>. The receiver is to take no action until this sequence
is received." 

I brought this to Google's attention and they said "we don't have such
issue with any of our customers" and "sending server will know what to
do from there", which seems bogus - qmail, sendmail and postfix all
expect RFC-compliant responses and choke on this.  On one hand I feel
that Google must fix this rather than the MTA (why should everyone else
work around their broken software?).  On the other hand, putting this
patch on our qmail servers dropped the size of our outgoing mail queue
by more than 1/3.

Here's the patch:

--- qmail-1.03/qmail-remote.c   1998-06-15 04:53:16.000000000 -0600
+++ qmail-1.03-571/qmail-remote.c       2011-04-25 11:39:07.513583926
-0600
 <at>  <at>  -158,7 +158,32  <at>  <at> 
     get(&ch);
     get(&ch);
   }
-  while (ch != '\n') get(&ch);
+  while (ch != '\n') 
+  {
+    // Postini can return a 571 SMTP code terminated with a '\r' but no
+    // '\n'.  The result is that we are trapped in this while loop
until
+    // saferead() times out and the message is drop()ed. This means a 
+    // message that should be a permanent failure is instead requeued
+    // continually until it ages out.  Try to catch and prevent this:
+    if (ch == '\r' && code == 571) 
+    {
+ 
+     // Cap smtptext with a '\n' so future uses of the string look
right
+      unsigned char LF;
+      LF = '\n';
+      if (!stralloc_append(&smtptext,&LF)) temp_nomem();
+ 
+     // Returning here potentially leaves a '\n' in the fd (if someone
+     // later correctly implements a 571 error with CRLF), but since 
+     // this means we will be quitting before we read() again we'll
+     // not worry about it.
+     return code;
+    }
+    else
+    {
+      get(&ch);
+    }
+  }

   return code;
 }

Re: "connection died" errors and Postini - patch

Thus said Tregaron Bayly on Tue, 19 Jul 2011 11:13:09 MDT:

> I brought this to Google's attention and they said "we don't have such
> issue with any of our customers" and "sending server will know what to
> do from  there", which seems bogus  - qmail, sendmail and  postfix all
> expect RFC-compliant responses and choke on this.

Why do  companies think this  an acceptable response to  broken software
and poor software  design? This is probably an attempt  on their part at
some kind  of elaborate anti-spam technique.  I can see no  other reason
why they would reject an email with a 5xx permanent failure but not give
the complete \r\n to terminate the response except this. Yes, I'm giving
google developers the benefit of the  doubt... I hear that they hire the
best.

Andy

Using systemd to start qmail/netqmail

FC9 had replaced sysv init scripts for the new init upstart. FC15 has
moved to a new init yet again. This time the init is systemd
http://en.wikipedia.org/wiki/Systemd

To have qmail/netqmail or my own indimail server run under systemd,
one needs to create a service configuration file
(/lib/systemd/system/qmail.service)

# cat > /lib/systemd/system/qmail.service
[Unit]
Description=qmail/netqmail service
After=local-fs.target network.target

[Service]
ExecStart=/var/qmail/bin/svscan /service
ExecStop=/var/qmail/bin/svc -dx /service/* /service/*/log
Type=simple
NonBlocking=yes

[Install]
WantedBy=multi-user.target

NOTE: You can use your own variation in ExecStart to start svscan
(using it with readproctitle, etc)

# systemctl enable qmail.service

The above command will create a link in
/etc/systemd/system/multi-user.target.wants

lrwxrwxrwx  1 root root   36 Jul 20 18:18 qmail.service ->
/lib/systemd/system/qmail.service

To start qmail/netqmail do

# systemctl start qmail.service

To stop qmail/netqmail do

# systemctl stop qmail.service

--
Regards Manvendra - http://www.indimail.org