We have an issue with some customers who refuse to accept ICMP traffic to their mail servers. It seems that they have put Mordac, preventer of information services in charge of their firewall policy (http://en.wikipedia.org/wiki/List_of_minor_characters_in_Dilbert#Mordac). My mail logs are showing that customers who specifically disallow ICMP traffic have many "Connection Reset" entries in our logs: Oct 14 08:00:50 mailsrv sendmail[2024]: m9ED0Yf5002021: to=<customername at customer.org>, delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=42476, relay=mail.customer.org. [XX.XX.XX.XX], dsn=4.0.0, stat=Deferred: Connection reset by mail.customer.org. I have disabled pmtu discovery on our routers as well as on all our outbound mail servers. Is there anything else I can do on our side to help the situation?
Sean Carolan wrote:> We have an issue with some customers who refuse to accept ICMP traffic > to their mail servers. It seems that they have put Mordac, preventer > of information services in charge of their firewall policy > (http://en.wikipedia.org/wiki/List_of_minor_characters_in_Dilbert#Mordac).BUT ICMP IS BAD!!!!!?????> My mail logs are showing that customers who specifically disallow ICMP > traffic have many "Connection Reset" entries in our logs: > > Oct 14 08:00:50 mailsrv sendmail[2024]: m9ED0Yf5002021: > to=<customername at customer.org>, delay=00:00:16, xdelay=00:00:16, > mailer=esmtp, pri=42476, relay=mail.customer.org. [XX.XX.XX.XX], > dsn=4.0.0, stat=Deferred: Connection reset by mail.customer.org. > > I have disabled pmtu discovery on our routers as well as on all our > outbound mail servers. Is there anything else I can do on our side to > help the situation?So you basically broke your internet connection because of stupid customers? No, there isn't anything you can do on your side - especially if you don't know how large their MTU is set (which you cannot discover, as they forbid you to do so). So you can only hope that you get exactly the same MTU as they have (and that there is nothing inbetween which has a lower MTU). It is their problem. If they don't want to play by the rules, they should have to sit out the problems they themselves created. Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20081014/8ef831f1/attachment-0003.sig>
Sean Carolan wrote on Tue, 14 Oct 2008 08:13:34 -0500:> My mail logs are showing that customers who specifically disallow ICMP > traffic have many "Connection Reset" entries in our logs:Could somebody explain why ICMP might play a role in mail delivery? Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Sean Carolan a ?crit :> We have an issue with some customers who refuse to accept ICMP traffic > to their mail servers. It seems that they have put Mordac, preventer > of information services in charge of their firewall policy > (http://en.wikipedia.org/wiki/List_of_minor_characters_in_Dilbert#Mordac). > > My mail logs are showing that customers who specifically disallow ICMP > traffic have many "Connection Reset" entries in our logs: > > Oct 14 08:00:50 mailsrv sendmail[2024]: m9ED0Yf5002021: > to=<customername at customer.org>, delay=00:00:16, xdelay=00:00:16, > mailer=esmtp, pri=42476, relay=mail.customer.org. [XX.XX.XX.XX], > dsn=4.0.0, stat=Deferred: Connection reset by mail.customer.org. > > I have disabled pmtu discovery on our routers as well as on all our > outbound mail servers. Is there anything else I can do on our side to > help the situation?Consider setting a small MTU (or MSS, ....) for the borked networks instead of changing your setup globally. something like ip route add 192.0.2.0/24 via 10.0.0.1 mtu 1000