OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: LMTP?

Re: LMTP?

Amos Gouaux (amos+lists.postfixutdallas.edu)
24 Nov 1999 18:43:41 -0600

>>>>> On Tue, 23 Nov 1999 18:16:18 +0000,
>>>>> valery brasseur <vbrasseuratos-group.com> (vb) writes:

vb> Here is the patch a use on the lmtp part of postfix for using LMTP on
vb> Solaris (note that these diffs are not necessary for Linux !)
vb> It's seems that the probleme come from the interpretation of the return
vb> code from cyrus-deliver.

Thanks! Actually, this prompted me to do a little tinkering...

vb> --- lmtp/lmtp_proto.c Tue Apr 20 09:42:45 1999
vb> +++ /postfix-19990906/lmtp/lmtp_proto.c Thu Sep 2 15:04:57 1999
vb> -445,12 +445,12
vb> if (resp->code / 100 == 2) {
vb> ++nrcpt;
vb> recipient_list_add(&survivors, rcpt->offset,
rcpt-> address);
vb> - } else if (resp->code == 550
vb> + } else /* if (resp->code == 550
vb> && strncmp(resp->str, "550 5.1.1", 9)
vb> == 0) {
vb> deliver_completed(state->src, -1);
state-> status |= -1;
rcpt-> offset = 0;
vb> - } else {
vb> + } else */ {o
vb> lmtp_rcpt_fail(state, resp->code, rcpt,
vb> "host %s said: %s",
session-> host,
vb> translit(resp->str, "\n", "
vb> "));

Yup, with this block of code commented out, these 550 5.1.1 (unknown
user) results get bounced back to the sender, instead of sitting
lodged in the queue. Of course, I've got to ask why this code was
put in here and what's it supposed to do? I looked at the smtp code
in the snapshot-19991123 and it doesn't do that. In fact, it would
appear that this lmtp patch is the only thing that's currently using
the recipient_list functions. Maybe this is a new thing that hasn't
yet been applied to other services?

I started doing some more tinkering as well (uh oh). One problem I
noticed was that the -u user -g group options really weren't
working. Here's the old master.cf entry for lmtp:

lmtp unix - n n - - lmtp -v -v
    lmtp -u cyrus -g cyrus /usr/local/cyrus/bin/deliver -l -e -D

The problem is that the first invocation (`lmtp -v -v') resulted in
the owner and group being set to nobody, so the second invocation
didn't have rights to setuid to cyrus:cyrus. At least that's how it
seemed because I had to chmod o+rx deliver to get it to work. Ah, I
suppose I could have moved those options to the first invocation.
But then why was it requiring both of these invocations anyway?

I was curious if this service could be made more like the others.
So I fiddled with the code, using pipe.c as an example, and came up
with the following master.cf entry:

lmtp unix - n n - - lmtp -v -v
    user=cyrus argv=/usr/local/cyrus/bin/deliver -e -l -D

This works pretty well. However, I've noticed two oddities, which
probably indicates that I'm doing something wrong somewhere. First,
after the message has been apparently delivered, lmtp/deliver hangs
around for a while. Maybe that's how single_server_main things
work, I don't know.

The other oddity, one that's a bit more of a problem, it would seem
that multiple incoming requests aren't handled too well. If I send
a message (using the Postfix sendmail command), and then turn around
and immediately fire off another, I see something like this in the
logs:

Nov 24 17:35:01 area52 postfix/lmtp[15148]: chroot (none) user (none)
Nov 24 17:35:01 area52 postfix/lmtp[15148]: watchdog_create: 80588 18000
Nov 24 17:35:01 area52 postfix/lmtp[15148]: watchdog_stop: 80588
Nov 24 17:35:01 area52 postfix/lmtp[15148]: watchdog_start: 80588
Nov 24 17:35:01 area52 postfix/lmtp[15148]: connection established
Nov 24 17:35:01 area52 postfix/lmtp[15148]: master_notify: status 0
Nov 24 17:35:01 area52 postfix/lmtp[15148]: deliver_request_initial: send initial status
Nov 24 17:35:01 area52 postfix/lmtp[15148]: print int: 0
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read string: active
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read string: 42DAC2473A
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 107
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 299
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read string: area52.utdallas.edu
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read string: amosutdallas.edu
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read string:
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 943486500
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 47
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read string: amosarea52.utdallas.edu
Nov 24 17:35:01 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 0
Nov 24 17:35:01 area52 postfix/lmtp[15148]: deliver_request_get: file active/42DAC2473A
Nov 24 17:35:01 area52 postfix/lmtp[15148]: deliver_message: from amosutdallas.edu
Nov 24 17:35:01 area52 postfix/lmtp[15148]: deliver_message: file active/42DAC2473A
Nov 24 17:35:01 area52 postfix/lmtp[15148]: connecting to deliver
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 220 area52 LMTP ready
Nov 24 17:35:01 area52 postfix/lmtp[15148]: > deliver: LHLO area52.utdallas.edu
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250-area52
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250-8BITMIME
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250-ENHANCEDSTATUSCODES
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250-AUTH PLAIN
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250 PIPELINING
Nov 24 17:35:01 area52 postfix/lmtp[15148]: server features: 0x6
Nov 24 17:35:01 area52 postfix/lmtp[15148]: Using LMTP PIPELINING, TCP send buffer size is 16384
Nov 24 17:35:01 area52 postfix/lmtp[15148]: match_hostaddr: ~? 0.0.0.0
Nov 24 17:35:01 area52 postfix/lmtp[15148]: match_hostname: deliver ~? 0.0.0.0
Nov 24 17:35:01 area52 postfix/lmtp[15148]: match_list_match: : no match
Nov 24 17:35:01 area52 postfix/lmtp[15148]: match_list_match: deliver: no match
Nov 24 17:35:01 area52 postfix/lmtp[15148]: > deliver: MAIL FROM:<amosutdallas.edu>
Nov 24 17:35:01 area52 postfix/lmtp[15148]: > deliver: RCPT TO:<amosarea52.utdallas.edu>
Nov 24 17:35:01 area52 postfix/lmtp[15148]: > deliver: DATA
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250 2.1.0 ok
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 250 2.1.5 ok
Nov 24 17:35:01 area52 postfix/lmtp[15148]: < deliver: 354 go ahead
Nov 24 17:35:01 area52 postfix/lmtp[15148]: > deliver: .
Nov 24 17:35:02 area52 postfix/lmtp[15148]: < deliver: 250 2.1.5 Ok
Nov 24 17:35:02 area52 postfix/lmtp[15148]: 42DAC2473A: to=<amosarea52.utdallas.edu>, relay=deliver, delay=2, status=sent (250 2.1.5 Ok)
Nov 24 17:35:02 area52 postfix/lmtp[15148]: name_mask: resource
Nov 24 17:35:02 area52 postfix/lmtp[15148]: name_mask: software
Nov 24 17:35:02 area52 postfix/lmtp[15148]: deliver_request_final: send: "" 0
Nov 24 17:35:02 area52 postfix/lmtp[15148]: print string:
Nov 24 17:35:02 area52 postfix/lmtp[15148]: print int: 0
Nov 24 17:35:02 area52 postfix/lmtp[15148]: master_notify: status 1
Nov 24 17:35:02 area52 postfix/lmtp[15148]: connection closed
Nov 24 17:35:02 area52 postfix/lmtp[15148]: watchdog_stop: 80588
Nov 24 17:35:50 area52 postfix/lmtp[15148]: watchdog_start: 80588
Nov 24 17:35:50 area52 postfix/lmtp[15148]: connection established
Nov 24 17:35:50 area52 postfix/lmtp[15148]: master_notify: status 0
Nov 24 17:35:50 area52 postfix/lmtp[15148]: deliver_request_initial: send initial status
Nov 24 17:35:50 area52 postfix/lmtp[15148]: print int: 0
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read string: active
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read string: 7EB2B2473F
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 107
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 299
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read string: area52.utdallas.edu
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read string: amosutdallas.edu
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read string:
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 943486550
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 47
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read string: amosarea52.utdallas.edu
Nov 24 17:35:50 area52 postfix/lmtp[15148]: mail_scan_any: read long integer: 0
Nov 24 17:35:50 area52 postfix/lmtp[15148]: deliver_request_get: file active/7EB2B2473F
Nov 24 17:35:50 area52 postfix/lmtp[15148]: deliver_message: from amosutdallas.edu
Nov 24 17:35:50 area52 postfix/lmtp[15148]: fatal: unknown attribute name: /usr/local/cyrus/bin/deliver
Nov 24 17:35:50 area52 postfix/lmtp[15148]: fatal: unknown attribute name: /usr/local/cyrus/bin/deliver
Nov 24 17:35:51 area52 postfix/master[15131]: warning: process /usr/local/postfix/lib/lmtp pid 15148 exit status 1

Is that because some lmtp processes have not yet shutdown? Should
lmtp be using multi_server_main instead? Though, it doesn't seem
like any of the other services are using that.

Is there some way to have lmtp wrap things up a bit faster instead
of waiting around for a while for things to end?

Nov 24 18:02:04 area52 postfix/lmtp[15253]: < deliver: 250 2.1.5 Ok
Nov 24 18:02:04 area52 postfix/lmtp[15253]: C395924718: to=<amosarea52.utdallas.edu>, relay=deliver, delay=1, status=sent (250 2.1.5 Ok)
Nov 24 18:02:04 area52 postfix/lmtp[15253]: name_mask: resource
Nov 24 18:02:04 area52 postfix/lmtp[15253]: name_mask: software
Nov 24 18:02:04 area52 postfix/lmtp[15253]: deliver_request_final: send: "" 0
Nov 24 18:02:04 area52 postfix/lmtp[15253]: print string:
Nov 24 18:02:04 area52 postfix/lmtp[15253]: print int: 0
Nov 24 18:02:04 area52 postfix/lmtp[15253]: master_notify: status 1
Nov 24 18:02:04 area52 postfix/lmtp[15253]: connection closed
Nov 24 18:02:04 area52 postfix/lmtp[15253]: watchdog_stop: 80588
Nov 24 18:02:04 area52 postfix/lmtp[15253]: watchdog_start: 80588

Nov 24 18:03:44 area52 postfix/lmtp[15253]: idle timeout -- exiting
Nov 24 18:03:44 area52 postfix/lmtp[15253]: > deliver: QUIT
Nov 24 18:03:44 area52 postfix/lmtp[15253]: smtp_get: EOF

I've put the code out on ftp if folks wish to point out the err of
my ways:

ftp://ftp.utdallas.edu/pub/staff/amos/postfix/lmtp-19990427-01.tar.gz

Amos

This archive was generated by hypermail 2.0b3 on Wed Nov 24 1999 - 23:38:29 CST