On Sat, Jun 22, 2013 at 03:25:36AM +0600, Denis Fateyev wrote: > > Hello Gilles, > On Fri, Jun 21, 2013 at 8:28 PM, gilles <[1][email protected]> wrote: > > User gilles has just rebuilt a portable snapshot, available from: > > [2]http://www.OpenSMTPD.org/archives/opensmtpd-201306211627p1.tar.gz > A summary of the content of this snapshot is available below. > Please test and let us know if it breaks something! > > 1) First of all, I see that two latest snapshots are already > "bootstrapped" and don't contain "bootstrap" script, is it default > behavior since the previous snapshot? I'm asking because previous > snapshots (earlier than Jun 07) and latest stable release (5.3.3p1) > contain "bootstrap".
Right, we started to ship tarballs with a configure script. > 2) PID subsystem is working fine, tested on RHEL 5 and 6, Debian 6 and > Ubuntu 12.04. but I've noticed that .sock file still present after > service stop. I believe this behavior has been broken somewhere in > snapshots between the latest stable release and the latest snapshot. I don't think it got broken, it probably never worked actually. I'll have a look. > 3) Process names are now correct (please check that if I'm wrong): > ----------------- previous behavior (stable version) ----------------- > Jun 21 14:07:03 ovz1-i386 smtpd[623]: info: OpenSMTPD 5.3.3p1 starting > Jun 21 14:07:03 ovz1-i386 smtpd[624]: info: startup > Jun 21 15:40:34 ovz1-i386 eduler[633]: info: scheduler handler exiting > Jun 21 15:40:34 ovz1-i386 nsfer[631]: info: mail transfer agent exiting > Jun 21 15:40:34 ovz1-i386 kup[628]: info: lookup agent exiting > Jun 21 15:40:34 ovz1-i386 ue[632]: info: queue handler exiting > Jun 21 15:40:34 ovz1-i386 trol[627]: info: control process exiting > Jun 21 15:40:34 ovz1-i386 ter[630]: info: mail filter exiting > Jun 21 15:40:34 ovz1-i386 ivery[629]: info: mail delivery agent exiting > Jun 21 15:40:34 ovz1-i386 p[634]: info: smtp server exiting > Jun 21 15:40:34 ovz1-i386 iv][624]: warn: parent terminating > ----------------- current behavior (latest snapshot) ----------------- > Jun 21 15:41:09 ovz1-i386 smtpd[2505]: info: OpenSMTPD 201306211627p1 > starting > Jun 21 15:41:09 ovz1-i386 smtpd[2506]: info: startup > Jun 21 15:41:33 ovz1-i386 smtpd[2514]: info: scheduler handler exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2512]: info: mail filter exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2513]: info: mail transfer agent > exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2515]: info: smtp server exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2511]: info: mail delivery agent > exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2510]: info: lookup agent exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2508]: info: queue handler exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2509]: info: control process exiting > Jun 21 15:41:33 ovz1-i386 smtpd[2506]: warn: parent terminating Yes, I finally managed to fix that. > 4) "smtpscript" binary is now missing (I compared to latest stable > release but haven't check with previous snapshot). Is it correct? It got removed for some reason. I liked to have it though. Well... > 5) During message relay: I see that "smtp-out" tries to connect to > several MX servers simultaneously. For one outgoing example, it tries > to open several sessions in a short time. What happens if all > connections are established properly and are ready for accepting mail? > Would one message be sent through them all? Can "smtp-out" handle this > situation correctly? The connection strategy is a bit complicated, but it should work well enough for a large variety of use-case. The idea is that the MTA establishes and maintains a set of connections when it receives messages to send. When a connection is ready, it will dequeue the next message from the wait queue and send it. So a message will not be sent twice by different connections. > At least, I've noticed, that after successful relay through one session > "smtp-out" doesn't close others for the same message. > You can look at a piece of log below: here we have a successful relay > through one session (000000038ae32e21), but another one > (00000002cf237b1e) for the same message still open until connection > timeout. I think all the sessions (regardless of their validity or > state) should be closed forcefully after succeeded message relay > through one of them? > ----------------- cut ----------------- > Jun 21 16:44:07 ovz1-i386 smtpd[3985]: smtp-in: New session > 00000000b829a2ca from host 0@localhost [local] > Jun 21 20:44:07 ovz1-i386 smtpd[3985]: smtp-in: Accepted message > b829a2ca on session 00000000b829a2ca: > from=<[3][email protected]>, size=279, nrcpts=1, proto=ESMTP > Jun 21 20:44:07 ovz1-i386 smtpd[3985]: smtp-in: Closing session > 00000000b829a2ca > Jun 21 16:44:07 ovz1-i386 smtpd[3983]: smtp-out: Connecting to > smtp://IPv6:2a00:1450:4010:c03::1b:25 ([4]la-in-x1b.1e100.net) on > session 00000002cf237b1e... > Jun 21 20:44:09 ovz1-i386 smtpd[3983]: smtp-out: Connecting to > smtp://[5]74.125.143.27:25 ([6]la-in-f27.1e100.net) on session > 000000038ae32e21... > Jun 21 20:44:09 ovz1-i386 smtpd[3983]: smtp-out: Connected on session > 000000038ae32e21 > Jun 21 20:44:11 ovz1-i386 smtpd[3983]: relay: Ok for b829a2cabf86fb91: > session=000000038ae32e21, from=<[7][email protected]>, > to=<[8][email protected]>, rcpt=<->, source=192.168.0.100, > relay=74.125.143.27 ([9]la-in-f27.1e100.net), delay=4s, stat=250 2.0.0 > OK 1371847451 m8si2965234lbs.120 - gsmtp > Jun 21 20:44:12 ovz1-i386 smtpd[3983]: smtp-out: Closing session > 000000038ae32e21: 1 message sent. > Jun 21 20:45:10 ovz1-i386 smtpd[3983]: smtp-out: Error on session > 00000002cf237b1e: Connection timeout > Jun 21 20:45:10 ovz1-i386 smtpd[3983]: smtp-out: Disabling route [] <-> > IPv6:2a00:1450:4010:c03::1b ([10]la-in-x1b.1e100.net) for 800s > ----------------- cut ----------------- > You can argue that in this example the second session is invalid anyway > since it tries to use IPv6, but more important that it hasn't been > closed after the first one succeeded. Returning to the beginning of the > question, what would happen if they're both valid? It's not 2 connections for the same message, it's 2 connections for the same relay. The message is eventually handled by one of the connection. What happens here is that there is a mail to be sent to a certain domain, the MTA resolves the MX list, which turns out to contain an IPv6 and IPv4 address. It starts a new connection on the first, and, after a while, on the second. The idea is that if the second is reachable immediatly, we don't have to wait for the first one to timeout if we can send the message on the second. So after having sent the message the second connection closes since there is nothing left to do. And later, the first connection attempts times out. Eric. -- You received this email because you are subscribed to mailing list: [email protected] To unsubscribe, send mail with subject: [[email protected]] unregister
