On Sat, Jun 22, 2013 at 10:48:21PM +0600, Denis Fateyev wrote:
> 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 README.md in portable states:
Build
-----
cd opensmtpd*
./bootstrap # Only if you build from git sources
./configure
make
sudo make install
> > 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?
>
There are many reasons to that:
First, if you have several acceptable routes it can be more efficient to
use them concurrently. It is very common for hosts sending large volumes
to dispatch message through multiple connections/interfaces because that
allows faster throughput.
Then, if you attempt to establish several connections, even if you don't
use them right away it's preferable to not shut them down immediately as
it would be a waste of resource:
a- you already did the work to establish them
b- the scheduler may have work to dispatch which will benefit from them
c- if there's no work, then it doesn't cost more to shut them down than
to let them timeout
On a host that does a lot of outgoing trafic this has a very significant
impact on performances.
> 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.
>
They are logged as log_info(), standard logging.
--
Gilles Chehade
https://www.poolp.org @poolpOrg
--
You received this email because you are subscribed to mailing list:
[email protected]
To unsubscribe, send mail with subject:
[[email protected]] unregister
