How to solve "Deferred: Invalid argument" problems in sendmail (bounces bouncing)

I have a constant large number of items in my sendmail queue, most of them containing "Deferred: Invalid argument" in the "q" file.

I know most of these should be deliverable, but it seems sendmail is somehow sending something stupid to the receiving server (if it's even trying that at all) or something else, because these sit here for 5 days then hit my "postmaster" address.

It seems the majority of these emails are bounces.

In other words - my mail server is having problems delivering some bounces, so they sit for 5 days and then bounce into my postmaster account.

I notice that they all have a strange line: H?P?Return-Path: <g>

In case you can't see it - there's a strange character before the "g" (in "vi" it shows up as <<81>g>). This may or may not be a problem? I've no idea where it came from.

Below is an example file (domain names have been changed to protect against spam, but otherwise it's unedited).  The RPF line is a valid email address (well, it was before I obscured it to protect against spam).  It happens to be my own address, on a different server running the same version of sendmail as the server having the problem sending it.

Any help, clues, hints, advice, or anything you can provide would be most welcome!!!

[root@my mqueue]# pwd
[root@my mqueue]# grep -l "Deferred: Invalid argument" * |wc
     39      39     663

[root@my mqueue]# dir *fi9PMqwvt019196  
-rw-------    1 root     smmsp        1414 Oct 25 23:59 dfi9PMqwvt019196
-rw-------    1 root     smmsp         896 Oct 27 08:42 qfi9PMqwvt019196
[root@my mqueue]#
[root@my mqueue]# cat qfi9PMqwvt019196
MDeferred: Invalid argument
${daemon_flags}b h
MDeferred: Invalid argument
H?P?Return-Path: <g>
H??Received: from localhost (localhost)
        by (8.12.10/8.12.10) id i9PMqwvt019196;
        Mon, 25 Oct 2004 23:59:17 GMT
H?D?Date: Mon, 25 Oct 2004 23:59:17 GMT
H?F?From: Mail Delivery Subsystem <>
H?x?Full-Name: Mail Delivery Subsystem
H?M?Message-Id: <>
H??To: postmaster
H??MIME-Version: 1.0
H??Content-Type: multipart/report; report-type=delivery-status;
H??Subject: Postmaster notify: see transcript for details
H??Auto-Submitted: auto-generated (postmaster-notification)
[root@my mqueue]#
[root@my mqueue]# cat dfi9PMqwvt019196
This is a MIME-encapsulated message


The original message was received at Wed, 20 Oct 2004 23:13:02 GMT
from localhost
with id i9KMWfDp019382

   ----- The following addresses had permanent fatal errors -----

   ----- Transcript of session follows -----
<>... Deferred: Invalid argument
Message could not be delivered for 5 days
Message will be deleted from queue

Content-Type: message/delivery-status

Reporting-MTA: dns;
Arrival-Date: Wed, 20 Oct 2004 23:13:02 GMT

Final-Recipient: RFC822;
Action: failed
Status: 4.4.7
Remote-MTA: DNS;
Last-Attempt-Date: Mon, 25 Oct 2004 23:59:17 GMT

Content-Type: text/rfc822-headers

Return-Path: <>
Received: from localhost (localhost)
        by (8.12.10/8.12.10) id i9KMWfDp019382;
        Wed, 20 Oct 2004 23:13:02 GMT
Date: Wed, 20 Oct 2004 23:13:02 GMT
From: Mail Delivery Subsystem <>
Message-Id: <>
To: <>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
Subject: Return receipt
Auto-Submitted: auto-generated (return-receipt)


[root@my mqueue]#
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ChrisDrakeAuthor Commented:
My problem still remains, but I've investigated the "H?P?Return-Path: <g>" situation a bit more and it looks like that is a red herring: I've found some normal queue messages with the same thing that do go through OK (not "Invalid argument" one though).

I think the <<81>g> part is a sendmail macro, since my file specifies "H?P?Return-Path: <$g>", and the queue file probably needs to replace the "$" so it know the expand that macro when the time comes to do the sending.

I also manually edited one of the queue files, replace the <<81>g> with a valid address, and tried "sendmail -q" (to reprocess my queue) and the queued message still remained there.

I remain stumped !
Yes, the "H?x?" and "<<81>g>" strings are part of sendmail's internal message format. Don't worry about it.

This draws my attention:

Reporting-MTA: dns;
Arrival-Date: Wed, 20 Oct 2004 23:13:02 GMT

This suggests to me that your mailserver's traffic is being rejected by the "" mailserver. It either doesn't like something your mailserver is saying, or it is misconfigured and is therefore rejecting you.

If you are able to send E-Mail to other places without any problems, I would tend to think the problem is on the "" mailserver.
ChrisDrakeAuthor Commented:
Sorry to not explain the domains better: is the main domain my server sends mails out from; here's what's in my file:

# my name for error messages

I specifically set this because some broken mailers won't accept "MAIL FROM: <>" and I absolutely must get bounces back to all senders. is the same server; it's the "main name" that sendmail runs under; what gets added on the end of "root@" if you just type the "Mail" command in a shell.  Here's my "hosts" file, which I guess is where this comes from (not my real IP tho):-       localhost localhost.localdomain localhost

I run a bunch of other virtual domains, and it's necessary that my server uses "otherdomain" so that customers don't get confused by headers and such.

I think you're correct (in a roundabout way) in suggesting the problem is on the "" mailserver... that's my mailserver, and I reccon the problem is likley there: If only we could work out what it is!!

Is there a debugging mode where sendmail can run and output a detailed log of everything it's trying to do?  Maybe I can shut down sendmail, restart it in this mode, tell it to process my mailqueue, and see what the heck it's trying to do with all those queued things.  Maybe if we had some idea what, exactly, this "argument" is that's invalid we'd be some ways to working out what to change :-)

Hmm. Maybe I could search the source code to see what kinds of things produce that error?
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

ChrisDrakeAuthor Commented:
Hmm. The mystery deepens - no "Invalid argument" in the binary nor source code.

[cnd@my sendmail-8.12.10]$ pwd
[cnd@my sendmail-8.12.10]$ grep -r  'Invalid argument' /usr/sbin/sendmail
[cnd@my sendmail-8.12.10]$ grep -r 'Invalid argument' .
./RELEASE_NOTES:                like "Cannot create qfXXXXXX: Invalid argument"
./libsmutil/lockfile.c: **  previous fcntl will fail with "Invalid argument" errors.
./sendmail/conf.c:      **  previous fcntl will fail with "Invalid argument" errors.
./libsmdb/smdb.c:       **  previous fcntl will fail with "Invalid argument" errors.
./obj.Linux.2.4.21-4.ELsmp.i686/libsmutil/lockfile.c:   **  previous fcntl will fail with "Invalid argument" errors.
./obj.Linux.2.4.21-4.ELsmp.i686/sendmail/conf.c:        **  previous fcntl will fail with "Invalid argument" errors.
./obj.Linux.2.4.21-4.ELsmp.i686/libsmdb/smdb.c: **  previous fcntl will fail with "Invalid argument" errors.
./obj.Linux.2.4.21-15.ELsmp.i686/sendmail/conf.c:       **  previous fcntl will fail with "Invalid argument" errors.
./obj.Linux.2.4.21-15.ELsmp.i686/libsmutil/lockfile.c:  **  previous fcntl will fail with "Invalid argument" errors.
[cnd@my sendmail-8.12.10]$
Hmmm.... I'm thinking it might have to do not with the format of the E-Mail, but with how sendmail is called when it is given the E-mail.

How is this E-Mail being submitted to sendmail?
Could you post the relevant entries from the log file?
ChrisDrakeAuthor Commented:
OK - Here's another one.  The bounce has been sitting in my mailq for some time now.  The original email was sent like this:-

/usr/sbin/sendmail -i -N delay,failure -R full -f "k***@***" -- "y***"

However, the mailserver is not working, so the original sat for 5 days until sendmail gave up on it, and since then, the bounce has been stuck in my queue.

Here's the log file from the original.

Oct 22 03:46:57 my sendmail[5379]: i9M3kuf3005379: to=y***, ctladdr=k***@*** (8/12), delay=00:00:01, xdelay=00:00:00, mailer=relay, pri=39575, relay=[] [], dsn=2.0.0, stat=Sent (i9M3kvDn005383 Message accepted for delivery)
Oct 22 03:52:57 my sendmail[5385]: i9M3kvDn005383: to=<y***>, delay=00:06:00, xdelay=00:06:00, mailer=esmtp, pri=39649, [], dsn=4.0.0, stat=Deferred: Connection timed out with
Oct 22 04:42:51 my sendmail[12228]: i9M3kvDn005383: to=<y***>, delay=00:55:54, xdelay=00:06:00, mailer=esmtp, pri=129649, [], dsn=4.0.0, stat=Deferred: Connection timed out with
[ lots of entries skipped ]

Then here's what appears to be the bounce that's now stuck in the queue

Oct 28 02:16:41 my sendmail[30551]: i9R3r5vu021108: to=<k***@***>, delay=20:59:17, xdelay=00:00:01, mailer=esmtp, pri=1844510, [], dsn=4.0.0, stat=Deferred: Invalid argument
Oct 28 05:16:03 my sendmail[30813]: i9R3r5vu021108: to=<k***@***>, delay=23:58:39, xdelay=00:00:00, mailer=esmtp, pri=1934510, [], dsn=4.0.0, stat=Deferred: Invalid argument

By coincidence, something unrelated was actually mailled directly to k***@*** - so here's the log entries showing that this email address is receiving OK, followed by sendmail failing to deliver the bounce again:-

Oct 28 21:27:18 my sendmail[21800]: i9SLRGPH021800: to=k***@***, ctladdr=help@*** (0/0), delay=00:00:02, xdelay=00:00:00, mailer=relay, pri=51754, relay=[] [], dsn=2.0.0, stat=Sent (i9SLRIvq021809 Message accepted for delivery)
Oct 28 21:27:24 my sendmail[21811]: i9SLRIvq021809: to=<k***@***>, delay=00:00:06, xdelay=00:00:06, mailer=esmtp, pri=51951, [], dsn=2.0.0, stat=Sent (4-0828838842 Message accepted for delivery)
Oct 28 21:46:25 my sendmail[13895]: i9R3r5vu021108: to=<k***@***>, delay=1+16:29:01, xdelay=00:00:00, mailer=esmtp, pri=3284510, [], dsn=4.0.0, stat=Deferred: Invalid argument

I'm wondering if maybe it's some kind of obscure bug inside of the sendmail I'm running perhaps?

[root@my mqueue]# Oct 28 23:34:56 my sm-msp-queue[15030]: starting daemon (8.12.10):
Make sendmail deliver the stalled message in verbode mode. Execute:
   sendmail -v -qI_queueu_id_
   sendmail -v -qIi9R3r5vu021108

One possible explanation: "***" server is misconfigure (or broken) and does not accept bounce messages (messages with envelope sender set to <>).
It is rare but happens. Such doamins are listed in DSN list at

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ChrisDrakeAuthor Commented:
Hi anfi - great idea... it's given me a clue to try later (modifying my DNS so I can force sendmail to connect instead to a proxy so I can see what is being said by whom).

Here's what I just tried (verbatim - no alterations) - but I've told my sendmail never to use <> already because I need my DSN's to get back to the sender more than I care about my postmaster getting bounced DSN's :-)

[root@my root]# sendmail -v -qIiA4Mpfao009544

Running /var/spool/mqueue/iA4Mpfao009544 (sequence 1 of 1)
<>... Connecting to via esmtp...
<>... Deferred: Invalid argument
[root@my root]# telnet 25
Connected to (
Escape character is '^]'.
220 ESMTP MailMax 5.5 Fri, 05 Nov 2004 12:52:01 +0100
EHLO Hello [] Pleased to meet you
250 HELP
250 <>... Sender ok
250 Recipient <> Ok
354 Enter Mail, end with "." on a line by itself

Connection closed.
[root@my root]#
ChrisDrakeAuthor Commented:

I edited the "q" file, adding a suffix for a domain I own to the recipient email address in order to force sendmail to connect to a different machine.  On the different machine, I ran a proxy on port 25 which just echoed everything to the real SMTP destination.  Guess what?  My sendmail is not even iniating a connection out to the remote machine!! [I confirmed this by noticing that it fails immediately on all my "Deferred" emails - "immediately" is too fast - some of them take a long time to accept the connection]

[root@my etc]# sendmail -v -qIiA4Mpfao009544    

Running /var/spool/mqueue/iA4Mpfao009544 (sequence 1 of 1)
<>... Connecting to via esmtp...
<>... Connecting to via esmtp...
<>... Deferred: Invalid argument

(on my proxy machine - no connection ever arrived)

[root@my etc]# telnet 25    
Connected to (
Escape character is '^]'.
220 ESMTP MailMax 5.5 Fri, 05 Nov 2004 13:09:35 +0100
221 closing connection
Connection closed by foreign host.
[root@my etc]#

(This test connection did work on my proxy of course) - here's the proxy's output:-

# perl -client -server -open -strip
Connected to for client connections thru
Connected to server
Accepted client
220 ESMTP MailMax 5.5 Fri, 05 Nov 2004 13:09:35 +0100\r\n


221 closing connection\r\n

server  closed connection!  

This is interesting too: it thinks it's tried all of hotmails' MX's (again - it didn't - since this came up instantly with no delay - hotmail just aint that fast...)

[root@my mqueue]# sendmail -v -qIiA4Fpfao008039

Running /var/spool/mqueue/iA4Fpfao008039 (sequence 1 of 1)
<>... Connecting to via esmtp...
<>... Connecting to via esmtp...
<>... Connecting to via esmtp...
<>... Connecting to via esmtp...
<>... Deferred: Invalid argument

Could it be tring to use SSL or some other port besides 25 maybe?
ChrisDrakeAuthor Commented:

Here's the offending line:-

${daemon_flags}b h

Changed it to:-


... and it went out without any problems.

Now - I just gotta track down where the heck it's getting that "b h" from :-)
ChrisDrakeAuthor Commented:
*** FIXED *** (I hope)

I found this in my

O DaemonPortOptions=Port=smtp,Addr=, Name=MTA, Modifiers=bh

After noticing the the "b" was the cause of the problem, and I found this in the doco:-

Flag 'b' = bind to interface through which mail has been received for outgoing message.

Now - since these are all bounces, I guess it was trying to reach the internet after binding to
Alternatively You may configure your to relay locally submitted messages messages to public IP insted of
ChrisDrakeAuthor Commented:
Would this be the line I need to change for that?

In change:
   FEATURE(`msp', `[]')dnl
to IP address of you public interface
   FEATURE(`msp', `[aaa.bbb.ccc.ddd]')dnl
and generate new

It may create problems with delivering local mail when the interface is down.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Servers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.