El 08/02/13 10:02, Robert Schetterer escribió:
Am 08.02.2013 09:29, schrieb Angel L. Mateo:
Hello,

     I have list servers that send mails through another relay servers.
With this configuration all mail sent from our mail servers are
delivered through our relay servers. All servers use postfix (list
servers use 2.7.0 and relay 2.5.5)

     We are having problems with dns lookups to one domain. I know is not
a postfix problem, but a dns configuration error in that domain. But it
is affecting our servers.

     The problem is that whenever the relay server receives a mail
directed to that domain, I get the error "conversation with <mail
server> timed out while sending MAIL FROM". And as list server group
messages, all recipients in that group as rejected.

as workaround you can use a a deditacted transport for that domain



     I've been looking for the problem on that domain and is a timeout
problem. Due to some problem in its configuration, I've never have an
answer (the domain exists, but it doesn't answer).

what does not answer ,their mailserver , your dns ?

Their DNS doesn't respond. If I query it manually with dig, I get a timeout with no answer.

        The problem I'm having is that my relay server has

smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_recipient_access hash:/etc/postfix/verified_recipient_checks, check_policy_service inet:127.0.0.1:10031, permit_mynetworks,permit_sasl_authenticated, reject_unauth_destination, check_recipient_maps, permit

and is timing out in the reject_unknown_recipient_domain. As the server doesn't have any answer, the smtp connection from my list servers are completely timing out.

I guess it could be a better behaviour if in this situation my relay server could return a 450 for this domain (at least, with this behaviour my list server could try with other recipients of the message)

you should invest more time in analyse the real problem
i.e some routing problems may cause it

Solving the problem with this particular domain (which is not mine), solves my problem now, but not future similar problems. So I think it would be better to avoid the situation.

--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 868888337

Reply via email to