Mailing List Archive: Strange behavior

Strange behavior

Feb 23, 2007, 5:45 AM

Post #1 of 6 (2224 views)

Hallo All,

Don’t know if this is strictly qmail related, but hopefully I will get a few pointers.
I have a standard LWQ install, with vpopmail. I have three virtual domains, all with FQDN.

I can send and receive fine to all three from outside our LAN. Problem arises sending from inside, specifically from an exchange server in the same LAN (Both are in the 10.2.32.xx range).

The first domain I set up was , let's say mail.first.com. With this there are no problems.
If I try to send from the exchange server to any of the domains added later, mail never arrives.
Let's say the second domain I added was mail.second.com.

H:\>telnet mail.second.com 25
Connecting To mail.second.com...Could not open connection to the host, on port
25: Connect failed

H:\>

Both domains resolve to the same ip address inside the LAN.

It seems as if qmail, or tcpserver, is listening on port 25 but only on one domain - is this possible?

Kind Regards,

Stef

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.18.3/697 - Release Date: 2/22/2007 11:55 AM

Re: Strange behavior [ In reply to ]

fabio.busatto at sikurezza

Feb 23, 2007, 6:23 AM

Post #2 of 6 (2154 views)

Permalink

On Fri, Feb 23, 2007 at 02:45:26PM +0100, Steffen Bisgaard wrote:
> Both domains resolve to the same ip address inside the LAN.
> It seems as if qmail, or tcpserver, is listening on port 25 but only on one domain - is this possible?

This is a nonsense.
Programs bind ports on ip addresses, not on hostnames.
So, if you start a program with a hostname, it resolves and then uses
the associated ip address.
Telnet clients do the same, they first resolve the hostname into an
ip address and then connect to it.

All domain-related stuff could only be done at application layer, but
the tcp connection cannot be blocked (there is no way for the server
to know which is the hostname typed in the client looking only at the
layers from transport to link).

So, if you resolve both hostnames in the same ip address, telnet will
connect to both, or none.

Bye
Fabio

RE: Strange behavior [ In reply to ]

steffen_bisgaard at sento

Feb 23, 2007, 6:47 AM

Post #3 of 6 (2148 views)

Permalink

This is a nonsense.
Programs bind ports on ip addresses, not on hostnames.
So, if you start a program with a hostname, it resolves and then uses the associated ip address.
Telnet clients do the same, they first resolve the hostname into an ip address and then connect to it.

All domain-related stuff could only be done at application layer, but the tcp connection cannot be blocked (there is no way for the server to know which is the hostname typed in the client looking only at the layers from transport to link).

So, if you resolve both hostnames in the same ip address, telnet will connect to both, or none.

Bye
Fabio

Thought so - thanks for the confirmation.

After a few kicks up a few backsides, our internal DNS servers have now had the appropriate MX records added and all is well.

Sorry for wasting everybody's time.

Stef

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.18.3/697 - Release Date: 2/22/2007 11:55 AM

Re: Strange behavior [ In reply to ]

brunni at netestate

Oct 16, 2014, 10:29 AM

Post #4 of 6 (1691 views)

Permalink

Hello Andy,

On Thu, Oct 16, 2014 at 11:17:40AM -0600, Andy Bradford wrote:
> Thus said Michael Brunnbauer on Thu, 16 Oct 2014 18:42:01 +0200:
>
> > does a log file entry
> >
> > delivery 40846: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/
> >
> > mean that there was an actual delivery attempt?
>
> Yes, it means that qmail attempted to deliver the message (hence an
> actual delivery id of 40846) to the SMTP server.

Are you sure? I got a pointer to qmail-tcpok from another participant.

qmail-remote reporting "temporary failure" without actually checking because
the destination server is in the current list of timeouts would perfectly
explain what I saw.

Regards,

Michael Brunnbauer

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Re: Strange behavior [ In reply to ]

amb-sendok-1416073700.ceajlgjoedhkhnfnoema at bradfo

Oct 16, 2014, 10:48 AM

Post #5 of 6 (1691 views)

Permalink

Thus said Michael Brunnbauer on Thu, 16 Oct 2014 19:29:59 +0200:

> > Yes, it means that qmail attempted to deliver the message (hence an
> > actual delivery id of 40846) to the SMTP server.
>
> Are you sure? I got a pointer to qmail-tcpok from another participant.

Yes, you're right, it does consult the tcp timeouts table before trying
to establish a connection. And yes, the fact that it didn't actually
connect to the server doesn't mean a qmail delivery attempt was not made
(it was made, hence the entry in your logs).

Andy
--
TAI64 timestamp: 4000000054400506

Re: Strange behavior [ In reply to ]

amb-sendok-1416073932.diclanholdfoiiklinkj at bradfo

Oct 16, 2014, 10:52 AM

Post #6 of 6 (1690 views)

Permalink

Thus said Michael Brunnbauer on Thu, 16 Oct 2014 19:29:59 +0200:

> qmail-remote reporting "temporary failure" without actually checking
> because the destination server is in the current list of timeouts
> would perfectly explain what I saw.

man qmail-tcpto has this to say about it:

After an SMTP connection attempt times out, qmail-remote
records the relevant IP address. If the same address fails
again (after at least two minutes with no intervening
successful connections), qmail-remote assumes that further
attempts will fail for at least another hour.

So qmail must have made at least 2 delivery attempts to the server and
received timeouts. After an hour it would automatically remove the
timeout from the tcpto file and the deliver might have succeeded if the
server is back up.

Andy
--
TAI64 timestamp: 40000000544005ed