Hi,
At times, my sendmail servers produce the following errors:
Aug 4 23:45:14 mailserver sendmail[30701]: o74DYEfr030701: SYSERR(root):
collect: I/O error on connection from mail.somedomain.com,
from=<someemail@somedomain.com>
I''ve read up on this error extensively and based on what various people
say, it''s network related as discussed here:
http://www.experts-exchange.com/OS/Unix/Q_24484577.html
(The expert comment right at the bottom of the page).
I just need to verify a bit discussed in the link above, specifically this bit
here:
* A firewall/router which is blocking ICMP packets which are used to tell a
remote host that it''s hit a smaller MTU and will need to send smaller
packets. ("Fragmentation Required but DF bit set")
I''m using shorewall 4.0.10. In my shorewall rules, I have this set:
AllowICMPs/ACCEPT net $FW
AllowICMPs/ACCEPT net loc
All my mail servers exist in the "loc" zone.
The AllowICMPs macro contains:
# cat macro.AllowICMPs
#
# Shorewall version 4 - AllowICMPs Macro
#
# /usr/share/shorewall/macro.AllowICMPs
#
# This macro ACCEPTs needed ICMP types
#
###############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE RATE USER/
# PORT(S) PORT(S) LIMIT GROUP
ACCEPT - - icmp fragmentation-needed
ACCEPT - - icmp time-exceeded
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
So is this enough to guarantee that the MTU discovery process that is meant to
take place between source (them) and destination (me) is actually working?
This sendmail SYSERR is annoying as it will show up for a week (from one
particular source where no mail will ever come from them - while most other
sources remain fine) and then go away for months while it works fine, then come
back for no apparent reason from the same sending source for another few days or
a week, then go away again.
Thanks.
Michael.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can''t live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
Cristian Rodríguez
2010-Aug-06 13:37 UTC
Re: Fragmentation Required but Dont-Fragment bit set
El 06/08/10 01:38, Michael Mansour escribió:> * A firewall/router which is blocking ICMP packets which are used to tell a remote host that it's hit a smaller MTU and will need to send smaller packets. ("Fragmentation Required but DF bit set")There is another broken router in your path, shorewall loads AllowICMPs rule by default, in order to ensure that you dont mess stuff up ;) ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 8/5/10 10:38 PM, Michael Mansour wrote:> > So is this enough to guarantee that the MTU discovery process that is > meant to take place between source (them) and destination (me) is > actually working?Yes -- but then it is also totally unnecessary since, unless you are silly enough to include a rule that blocks all ICMP, Shorewall always allows those packets even with a DROP or REJECT policy. And that is just a safeguard since those packets are RELATED to an existing connection, they are normally passed by Shorewall-generated rules which ACCEPT packets in the ESTABLISHED or RELATED states.> > This sendmail SYSERR is annoying as it will show up for a week (from > one particular source where no mail will ever come from them - while > most other sources remain fine) and then go away for months while it > works fine, then come back for no apparent reason from the same > sending source for another few days or a week, then go away again.This problem can occur at *any router between your firewall and the remote server*. The only other measure you can take is to set CLAMPMSS=Yes in shorewall.conf; that is only helpful if the MTU of your internet interface is less than that of the interface to your outgoing MTA. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can''t live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
Michael Mansour
2010-Aug-10 02:08 UTC
Re: Fragmentation Required but Dont-Fragment bit set
Hi Tom, Thanks for your reply. --- On Fri, 6/8/10, Tom Eastep <teastep@shorewall.net> wrote:> From: Tom Eastep <teastep@shorewall.net> > Subject: Re: [Shorewall-users] Fragmentation Required but Dont-Fragment bit set > To: shorewall-users@lists.sourceforge.net > Received: Friday, 6 August, 2010, 11:54 PM > On 8/5/10 10:38 PM, Michael Mansour > wrote: > > > So is this enough to guarantee that the MTU discovery > process that is > > meant to take place between source (them) and > destination (me) is > > actually working? > > Yes -- but then it is also totally unnecessary since, > unless you are > silly enough to include a rule that blocks all ICMP, > Shorewall always > allows those packets even with a DROP or REJECT policy. And > that is just > a safeguard since those packets are RELATED to an existing > connection, > they are normally passed by Shorewall-generated rules which > ACCEPT > packets in the ESTABLISHED or RELATED states. > > > > > This sendmail SYSERR is annoying as it will show up > for a week (from > > one particular source where no mail will ever come > from them - while > > most other sources remain fine) and then go away for > months while it > > works fine, then come back for no apparent reason from > the same > > sending source for another few days or a week, then go > away again. > > This problem can occur at *any router between your firewall > and the > remote server*. The only other measure you can take is to > set > CLAMPMSS=Yes in shorewall.conf; that is only helpful if the > MTU of your > internet interface is less than that of the interface to > your outgoing MTA.Yeah, the internet interface is set to 1500, and all MX servers underneath are set to 1500. The problem is fixed now, the way it was fixed, as quoted from the remote sender/admin: " I did some searches on the errors below and many people seem to have this issue with send mail servers and many things can be the culprit. I don''t feel it is our court to offer suggestions on your configuration but we have made the necessary changes on our end to move your name space out to a Linux server to successfully contact and send mail to your hosted companies. Why we are able to send mail via this Linux box and not off our main Windows Exchange mail server is a mystery to me. We have had Microsoft engineers pour over our config and they see nothing wrong with what we have in place. " We handle 10''s of thousands of emails every day for hundreds of clients our end, and this remote sender (running MS Exchange) are the only ones that have had trouble sending. Many MS Exchange servers send to our sendmail servers also with no problems. It''s interesting to me that in no change to routers, MTU''s, etc, that just a change their end from moving from MS Exchange to Linux fixed it. I personally believe the MTU Discovery is the problem and the MS Exchange server their end doesn''t honour the "Dont'' Fragment" bit setting. The reason? we receive their MAIL FROM, RCPT TO, but when the email hits the DATA stage, it times out after 4 hours (likely because of larger emails). After providing him with extensive details, I suggested he raise this with Microsoft to see if there''s any bugs with their TCP/IP stack implementation? Linux outbound their end obviously doesn''t have the issue. Regards, Michael.> -Tom > -- > Tom Eastep \ When I die, I want > to go like my Grandfather who > Shoreline, \ died > peacefully in his sleep. Not screaming like > Washington, USA \ all of the > passengers in his car > http://shorewall.net >------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can''t live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
On 8/9/10 7:08 PM, Michael Mansour wrote:> Hi Tom, > > Thanks for your reply.And thanks, Michael, for your update. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can''t live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev