Re: smtp_sender_dependent_authentication hanging
- Am 31.03.2013 00:13, schrieb Dennis Putnam:
> On 3/30/2013 6:48 PM, Reindl Harald wrote:do so
>>> myuser@... [in.mailjet.com]:587
>>> P.S. There is not a socket connection problem. telnet to port 587 works
>>> fine as does authentication and commands to send a test email
>> so in "sasl_passwd" you do not use the port
>> well, and if you would have provided this info at begin the
>> problem would be solved with ONE reply at all
>> [in.mailjet.com] is for port 25 as long you do dont specify [in.mailjet.com]:587
> First, my ISP blocks port 25 that is why 587 is needed. Second, I tried
> specifying the port in the passwd file and that did not work either. You
> must have woke up on the wrong side of the bed this morning to be so
> unnecessarily rude and ornery. Never mind. I'll find an other source for
if you change configurations, provide out of context ones and are not
able to provide requested infos multiple times i am sure there are
enough manpages and howtos to learn at your own
> you must have woke up on the wrong side of the bed this morningno, if someone has a question he has to provide asked informations
or simply shut up in my world and this world works well
- On Sun, Mar 31, 2013 at 12:22:43AM +0100, Reindl Harald wrote:
> > you must have woke up on the wrong side of the bed this morningIt works well for Reindl, who is yet to realise that he is not the
> no, if someone has a question he has to provide asked informations
> or simply shut up in my world and this world works well
only consciousness on the planet.
As for the OP, he should try again with the correct lookup key for
the SASL table, and the destination IP address added to debug_peer_list.
Since the SMTP client reports a timeout receiving the initial
greeting, a tcpdump capture is helpful to determine what's going
on after the TCP 3-way handshake.
If all there is is silence, perhaps the remote server is overloaded
or having trouble resolving the client's IP address to a name. It
is also possible that some rate-limiting system is throttling the
client, due to past login failures, or other policy reasons.
> E7B1E1FA81: conversation with in.mailjet.com[220.127.116.11] timed outAccording to the SMTP protocol definition, RFC 5321, the server
> while receiving the initial server greeting
> Obviously it was not really hung but just waiting for something.
sends the initial greeting before the client sends its first command.
RFC 5321 section 18.104.22.168.1 recommends 5-minute timeout for this
protocol stage. This is consistent with the Postfix default:
smtp_helo_timeout (default: 300s)
The Postfix SMTP client time limit for sending the HELO
or EHLO command, and for receiving the initial remote SMTP
Why does the server not greet? Perhaps the server is overloaded.
It's also possible that they don't want to talk to your system.
If you make a tcpdump recording, then I expect to see a lot of a