On Sat, Jun 22, 2013 at 8:13 PM, Eric Faurot <[email protected]> wrote:
> On Sat, Jun 22, 2013 at 03:25:36AM +0600, Denis Fateyev wrote: > > > > 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. > So, I can safely remove "./bootstrap" call from the package spec. BTW Then we need corrections in opensmtpd documentation (README.md, etc.) to reflect these changes. > 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. > Now I see. > > 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. > Now, it's more clear to me. But anyway, there is the corrected question then: why don't close all opened connection associated with relay if one of them succeeded (all others make no sense anymore)? Why should we wait for the second session's timeout (just let it go till 20:45:10 in the example above) if we know preliminary on 20:44:12 that we succeeded and don't need it? And, here is the question on another topic: about recent changes on https://github.com/poolpOrg/OpenSMTPD/issues/252 issue. Will those changes take place only with verbose logging as we have discussed before? Or, now it's default behavior with standard logging? It's a bit unclear since I haven't seen detailed info about real changes, and there is no associated commit in GitHub repo to check it out. --- wbr, Denis.
