Mail Receipt not returning

We have a RH6.1 based mail pop3&smtp server. The clients are NT4.0 running MSOutlook 97. In Outlook there's an option to receive notification once a mail has been received/read. This works fine on a local LAN level, but any mail sent to the outside never returns a received receipt. We have a firewall set up which I'm guessing may be part of the problem. Any thoughts?
Thanks

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.

Are you ready to take your data science career to the next step, or break into data science? With Springboard’s Data Science Career Track, you’ll master data science topics, have personalized career guidance, weekly calls with a data science expert, and a job guarantee.

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

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:

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.

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)

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,

There is very little that can be done, as a user to change your MTA - that's a system, network-wide issue.

Return-Receipt-To: used to be honored by the MTA (that would dend the receipt upon queing the message for the delivery). For mailing lists, this resulted in a single message setting off a cascade of hundred of receipts, and this was widely considered to be bad.

Hence DSN, whose specs I have not read - I wonder what the relevant RFC is?.

In principle, however, delivery DSN could be processed in either the MTA, MDA or MUA. (The *reading* notification can obviously happen in the MUA only.)

Since MUAs, and to some extent MDAs, are somewhat shielded from strict standard implementation, I'd put my money on DSN being processed by the MTA - meaning that if a receipt is not delivered, that would be my prime suspect.

And the issue would be the MTA at the receiving end (as the sending end can't do much, now can it?).

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.

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.

Featured Post

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.