Topic: mails server config to follow RFC 2821, section 5

[veeresh]

Hi,

We are not able to send mail to one of our clients. We always get the following error

deferral: Connected_to_xxx.xx.yy.zz_but_connection_died._(#4.4.2) and bounce back after few days.

when we contacted the system guys at the client side the give the following reply

Most problems with external email domains being able to send messages to abc.com are due to those domains' email relays incorrectly trying to connect to each of our listed mail relays.  After they fail to connect to the first relay, they immediately defer delivery. Eventually, after several more failed attempts, they bounce the message back to the sender. Our highest priority mail relay (mapper.mail.abc.com) as listed in the DNS MX records is not directly reachable from the Internet. Any external mail domain will get an immediate TCP reset (an unconditional disconnect) from our firewalls when attempting to connect to mapper.mail.abc.com. A compliant Mail Transfer Agent (MTA) would then try the next mail relay in the list quickly and seamlessly. To deliver mail to abc, their MTA must roll to our priority-200 MX smtp.dmz.abc.com. The external domain messaging administrator will need to check their mail server configuration to ensure that it properly rolls to lower priority MX records.  RFC 2821, section 5, requires MTAs to try all MX records.


Can   qmail on sme server be configured to follow RFC 2821, Section 5 as mentioned above ?  Any pointers to the above will be highly appreciated.Thanks and regardsVeeresh[/color]

[chris burnat]

Please open a ticket in the Bugtracker, see link below, The subject of your inquiry will best be dealt with there.
Select New Feature Request.

[CharlieBrady]

I''m quite sure that qmail implements RFC 2821, section 5, unless configured via smtproutes to use a specific mail relay server rather than DNS (SMTP SmartHost).

[veeresh]

We are using SME server as a mail server.

The mails are not reaching this client because SME server does not try delivering to secondary mx server of the client when it gets disconnected by the primary mx server.

I shall rise a new feature request in the bug tracker.

Thanks

Veeresh

[CharlieBrady]

I''m quite sure that qmail implements RFC 2821, section 5, ...

I take that back:

http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html

You can work around this problem for your client's domain by using the smtproutes control file.

Code: [Select]

mkdir -p /etc/e-smith/templates-custom/var/qmail/control/smtproutes
echo clients.domain.name: a.b.c.d > \
/etc/e-smith/templates-custom/var/qmail/control/smtproutes/10clients.domain.name
expand-template /var/qmail/control/smtproutes

Your client would have fewer problems if they fixed their DNS, or their firewall. They should be aware that qmail is very widely deployed.

As requested previously, please create a bug report.