Mail Receipt not returning

Do you have sendmail setup to masquerade outgoing emails as being from the domain? The remote mail server may be trying to return the receipt to the wrong system. To find out what's really happening will probably require the assistance of someone at a remote server. Get them to tell you what the "return receipt bounce" says.

Also, not all mailers will return such receipts.  Outlook always will.  Netscape will ask.  Some mailers (mailx, for example) don't support them at all.

Adjusted points from 5 to 10

jlevie: we do have masquerading set up on our firewall, but our mail server is outside that so it should not need to have that set up right?
chris: Are you saying that it matters what email program the receiver is using?
Thanks

Yes.  It matters what email program the receiver is using.

As for jlevie's point, he wasn't talking about firewalls at all but what kind of mail address rewriting your mail server is doing.  The idea being that the recipients may be sending the replies correctly, but the mail addrss rewriting on the mail server is making it such that these replies can not make their way back to the correct Outlook mailbox.

Yeah, chris is on the same track as what I was referring to. Sendmail can be set up to do header re-writing so that all of the emails, as they leave your server appear to come from a specific system (typically the actual mailserver) or, better yet, as if they come from the domain. If sendmail is not doing the masquerade, the source address can wind up being that of the client machine, which can't accept inbound email (it isn't accessible throught the firewall and in the case of a PC, doen't run sendmail), or it might be the "inside" name of the mailserver. Lots of possibilities for confusion...

The best method in to tell sendmail to masquerade as the domain. This makes addresses look like user@domain.com and gives you the freedom to change mailservers (adjusting the MX records accordingly) without breaking inbound email as everything is addressed to user@domain.com, not user@server.domain.com.

The easy way to do this is to just build a sendmail.cf from a ".mc" file and include:

MASQUERADE_AS(mydomain.com)
FEATURE(masquerade_envelope)
FEATURE(masquerade_entire_domain)

in the mc file. If this is all greek, let me know and I'll elaborate.

Ok, I just tried sending an email to my own, web-based(excite mail) account asking for a return receipt. I've looked at the headers on the mail I received and it has a field called Return-Receipt-To which has my correct email address in the form of user@domain.com. So I'm guessing my mail server IS set up to masqurade. Is there a way to check for sure without imposing. I mean the mail server is currently actively being used and I don't want to interfere with that....I don't have MSOutlook available outside our net, so I can't really test to see if I read it with it what will happen :(
Any suggestions?
jlevie: please feel free to elaborate, I'd still consider myself a newbie to Linux :)
Thanks

It's easy to check where mail to user@domain.com should go. You can do "nslookup -query=mx domain.com". Send me an email with a return receipt requested (jlevie@bellsouth.net) and I'll see if I can determine where the real problem is. I'm pretty sure I already know, but I need to see the email headers to tell you how to fix it.

Greetings.

In passing, it shoud be noted that the Return-Receipt-To: header is falling out of usage (and with -mailing-list related - reason). So a lot of MUAs are not onoring it at all, and that may have an import on your problem. The holy texts say modern receipt handling should be made via DSN - Delivery Status Notification?- (a TLA whose actual nature I am uncertain about, not to say it beats me completely)

Cheers,
    alf

Sorry: in my posting, "MUAs"should actually read "MTAs"

alf

Adjusted points from 10 to 19

So the conclusion is so far per chris_calabrese that it matters what email program the user is using to read the emails as to whether or not the receipt is returned, and this seems to be the case, because I've been able to get return receipts from outside the network. Alf, you say there's a way around this with DSN? Could you provide some more info as to what an MS Outlook user would need to do to get a return receipt, no matter what program is being used to read the said email? Or is this a possibility at all?
Thanks.

It will also matter what MTA an Outlook user is using. If they have Exchange as the MTA there are another whole range of possible problems. Actually, now that I think about it, I suspect the MTA may be where the problem is. I know that I've got Outlook users that use POP/IMAP and a sendmail server and they've never reported any problems with return receipt processing. On the other hand I've seen return receipts bouncing off exchange for no reason that I can discern and I've heard some complaints from Outlook/Exchange users about return receipts just disappearing into the void. I don't have any use for exchange, nor do know anything about it, so I don't know if the solution would lie in the exchange config or in outlook.

I'm not familiar with the term MTA, but I'm guessing it's mail transfer agent?
If yes, then it's most likely the case. It was just the default install of Outlook, so I'm guessing Exchange is the MTA. Now are you saying that it matters what the MTA is on the sender's machine, or the receiver's machine or both? Does anyone know how to change the MTA on Outlook, and to what? Also if the sender does change that, will it increase the chances of him/her receiving the return receipt from more if not all the users she sends email to?
Thanks,

Good summary... Now if I can a TLA to add to my mail system...

Actually it's the MUA that does the return receipt processing now, at least with all the clients that I've futzed with. And I'd say you're right in that DSN would also he handled by the client. It's really difficult to say in this case whether the problem is in the MUA or MTA, or both. It's certain that the problem lies at the remote site, and I'd bet on it being an Exhange/Outlook problem because of the screwy way that combo works.

Adjusted points from 19 to 30

Well, thank you all for your help. Most appreciated. It's hard to decide who to give the points to, but I think alf's is the most informative. Again thank you. Hopefully in the future, they'll standardize the return-receipts in a sensible fashion.