No transport provider was available for delivery to this recipient

When an Microsoft Outlook 2000 user sends a message to multiple recipients on a local machine and one of those addresses returns an error code, Sendmail instantly replies with a very specific error message, namely "550 5.1.1 joe@bar.com... User unknown".

Outlook chooses to ignore the specific username, and attributes the error message to every recipient of the e-mail when it informs the sender of the problem. with the message "No transport provider was available for delivery to this recipient." This is completely unhelpful to a sender who has 100 addresses in the To: field and needs to figure out the broken one.

The only way to fix this is to have Sendmail blindly accept every incoming e-mail from an Outlook client, and mail the sender a message about the error in a seperate email a minute later.

On December 9, 2002 I asked the DC SAGE mailing list if anyone knew how to quell local user unknown responses during mail delivery with sendmail and only follow up with a 550 e-mail after the connection closes.

Pete Jansson wrote back right away to say, "If you use interactive delivery, I don't think you can avoid the messages, because an MTA is required to issue the errors to indicate that the messages to those recipients won't be accepted. You could switch to queued delivery, in which case (I think), sendmail will just eat the entire message and then process it later during a queue run, at which time it would (attempt to) pass a MAILER-DAEMON message back to the sender."

Rob Banz also chimed in with the solution I had played around with earlier, saying "Send all of your users's outgoing email through a server that does no delivery, just relaying. Then the 'user unknown' message will happen between that server and the destination, and you're good-to-go."

I went with Pete's suggestion first, and after a little tinkering the answer for a single e-mail server on a local network seems to be:

This makes sendmail defer delivery on all messages. Basically sendmail will always reply with:

Then the message for local delivery to joe will sit in the queue for about 60 seconds before sendmail picks it up and attempts the final delivery. At that point it'll either drop it into the local mailbox or service the sender back a NDN message.

Update December 9, 2002: Messages appear to be sitting in the queue for 3 to 20 minutes before final delivery. I remedied this by directing all outgoing mail to a smarthost rather than attempting external delivery from the internal mail server. Pete also added another suggestion:

Sounds like you may have stuff blocking the queue, so you need to start additional queue runner processes. Add these two lines wherever you start sendmail:

The second one is for sendmail 8.12.3 and up, which has the separate mail submission queue for locally generated mail.

These lines tell sendmail to start persistent queue runner processes, running the queue every minute, and running up to 3 queue runner processes per queue per run. If you set this value higher, you can really get sendmail to push mail at high speed. Ditch the "-q1m" from the sendmail that has "-bd"; you've got queue running covered elsewhere now.

Remember, you're going to have a trade-off between immediate delivery with immediate "User unknown", and deferred delivery with supressed "User unknown."

Update December 10, 2002: Deferred delivery with frequent queue running seems to have solved the problems. All Microsoft Outlook 2000 users in the company now get informative error messages e-mailed to them from sendmail about a minute later instead of a meaningless message immediately. Everyone seems to be okay with the slight delay of e-mail delivery and we haven't had any more complaints from employees with large mailing lists.

If you're a sendmail admin searched the web like I did for this error message, this is probably the only useful article you found. If this information was helpful to you, please link to this article from your web page and discussion groups to help others find it.

Update January 21, 2003: Jerry Bazil from Triton Container International writes: "In WIN2K settings/controlpanel/mail/showprofiles/properties/properties/servers tab. Check 'my server requires authentication' for the outgoing mail server . In settings check 'use same settings as my incoming mail server'. I can now send email from my pop server account."

This solves the problem of a server which requires SMTP AUTH, not the problem I was having.

Found your article and wanted to provide some additional feedback. I tried the 1 minute queue trick and it worked great for the Outlook bad address bug.

The problem I encountered is that my anti-relay rules apparently don't take effect until the queue is run. The mail was returned to the wrong place (forged reply address, of course), and tons of bounces started. At that point the server went into a vicious spiral and was rapidly brought to its knees. I killed all the sendmail processes, flushed the queue, and returned the systemto immediate delivery mode. After that things have returned to normal.

At this point my feeling is that the Outlook user should go pester M$ and "get her money's worth" (yeah, right) and get the bug fixed. Alas, it's a corporate situation and Outlook is being used because of the group calendaring capability lacking from all open source clients, so I can't present an alternative.

Please let me know how you got here, if this page was useful to you, and your opinions.

Unless noted, all content on epistolary.org is © Copyright 1999-2008 to Rob Carlson with all rights reserved. All information is verified when possible, cited as appropriate and applied in the real world at your own risk. Send all feedback to rob@vees.net.

Leave a Reply