Frequently can't deliver large emails

[forrester12]

Often times my sendmail MTA can't deliver large emails (15+ megs) to a receiving MTA. Here's an example of what the log says when the attempt fails:

Aug 11 14:45:18 mail sm-mta[31009]: q76M18iZ014587: to=<vran2@unitedfresh.org>, delay=4+23:44:10, xdelay=00:21:57, mailer=esmtp, pri=28052803, relay=unitedfresh.org.1.0001.arsmtp.com. [204.232.236.144], dsn=4.0.0, stat=Deferred: 451 Remote connection lost - psmtp

I have speculated this to be a bug, a configuration issue, a network issue, or perhaps the remote MTA simply doesn't want to accept emails larger than a given size. I would like help establishing what exactly the cause is. If the problem is the remote host then I don't care but if the problem is local I need to see if I can fix it. Unfortunately I don't know how to establish which it is.

Are there particular configuration details I should be looking for in sendmail.mc? Do I need to use wireshark on the connection to figure out what is going on when the remote connection is lost? Can anyone recommend a troubleshooting strategy to narrow this down?

Version 8.13.6
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETUNIX NEWDB PIPELINING SASLv2 SCANF USERDB
XDEBUG

divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
# All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#

include(`/usr/share/sendmail-cf/cf/m4/cf.m4')dnl
VERSIONID(`$Id: mailserver.mc 1.0 11/09/03 $')dnl
OSTYPE(linux)dnl
DOMAIN(generic)dnl
dnl define(`confRUN_AS_USER', `sendmail:sendmail')dnl
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')
DAEMON_OPTIONS(`Port=26, Name=MTA2')
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
define(`confMAX_MESSAGE_SIZE', `50000000')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
FEATURE(`no_default_msa',`dnl')dnl
dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl The '-t' option will retry delivery if e.g. the user runs over his quota.
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`dnsbl', `sbl.spamhaus.org')dnl
EXPOSED_USER(`root')dnl
MAILER(local)dnl
MAILER(procmail)dnl
MAILER(smtp)dnl

LOCAL_CONFIG

Kcheckaddress regex -a@MATCH
^([0-9]+<@(aol|msn)\.com|[0-9][^<]*<@juno\.com)\.?>

C{RejectToLocalparts} friend you
C{RejectToDomains} public.com
C{RejectToWholestring} Undisclosed.Recipients

LOCAL_RULESETS
HTo: $>CheckTo

SCheckTo
R$={RejectToLocalparts}@$* $#error $: "553 Header error"
R$*@$={RejectToDomains} $#error $: "553 Header error"
R$*$={RejectToWholestring}$* $#error $: "553 Header error

 

[normntwrk]

Right off hand I'd say it was the receiving end as your Sendmail.mc file is set to 50 Meg

define(`confMAX_MESSAGE_SIZE', `50000000')dnl

You can test by sending one to yourself, if that fails then your sendmail.mc file hasn't been processed into the sendmail.cf file

make copies of both files

then

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

and restart sendmail


Norm

 

[forrester12]

The dropped connection problem appears even with emails as small as 15 megs. Unless I'm missing something, that's well short of the 50 meg limit here even considering BASE64 attachment overhead. I think we need to keep looking for a cause.