[quote user="ryanj"]

I can understand how and why the delivery confirmation works as it stands now, but I can't help but think that it's incorrect behavior.

[/quote]

It is really the FORWARDing mechanism that is at fault. Delivery to the maildrop should be the end of the SMTP journey for a message. The issue occurs when it is resent (original headers intact) with a new SMTP envelope, effectively a new message, that is also requesting delivery confirmation.

A 'copy' rule is probably a "more correct" method than the FORWARD file "hack".

I have a user with 2 local accounts.  One is for his normal email (smith@domain), one is a catch-all for his mobile phone that gets a copy of everything that comes into the original account(smithmobile@domain).  The problem is that smith@  is getting un-asked for delivery notifications for every piece of mail that is being forwarded to smithmobile@ and I cannot find a way to make it stop except for deleting the notification template, which is not an option, as it is used by various people.

 The issue is not related to an email client, as I have sent test mail through and watched the server create the notification email multiple times while I know he is not on the server.  I searched all over the Configuration menu to no avail, and am completely out of ideas.  Any help would be appreciated.

I suspect the mails contain a "Return-Receipt-To:" header which triggers a "Delivery Receipt" by the server when the message is delivered into a users maildrop.

This is different to the "Read Reciept" which is client based and (mostly, there is no standard) is requested by a "Disposition-Notification-To:" header.

IIRC Mercury can be set to not respond to "Delivery Receipt" requests in the Core config.

I've checked various pieces of mail for the "Return-Receipt-To:" header, but this doesn't seem to be present, or the cause of the issue.  As of this writing, I can't find anything that could be causing this unwarranted delivery receipt. 

[quote user="ryanj"]I've checked various pieces of mail for the "Return-Receipt-To:" header, but this doesn't seem to be present, or the cause of the issue.  As of this writing, I can't find anything that could be causing this unwarranted delivery receipt. [/quote]

Could you provide the full headers of one of the messages being sent for analysis?

I sent 2 emails to the user (smithm) from outside the domain and did not get delivery confirmations.  I was starting to wonder if I had gone crazy and if dilbert was right all along, but then I ran across this example of what I keep getting:

Received: from spooler by [domain] (Mercury/32 v4.51); 6 Apr 2009 09:18:13 -0400
X-Envelope-To: marksmobile@[domain]
Received: from spooler by [domain] (Mercury/32 v4.51)
  for <smithm@[domain]>;  6 Apr 2009 09:18:01 -0400
Resent-from: smithm@[domain]
Resent-Date: Mon, 6 Apr 2009 09:18:01 -0400
X-Autoforward: 1
From:    Mail Delivery System <postmaster@[domain]>
To:      smithm@[domain]
Date:    Mon, 6 Apr 2009 09:17:50 -0400
Subject: Delivery Confirmation

With reference to your message with the subject:
   "04-06-09 report"

Your message was successfully delivered to the following addresses:
   marksmobile@[domain]

------------------ Beginning of message follows --------------------

Received: from spooler by [domain] (Mercury/32 v4.51)
  for <smithm@[domain]>;  6 Apr 2009 09:17:34 -0400
Resent-from: smithm@[domain]
Resent-Date: Mon, 6 Apr 2009 09:17:34 -0400
X-Autoforward: 1
Return-path: <corbettk@[domain]>
Received: from [172.16.42.56] (172.16.42.56) by [domain] (Mercury/32 v4.51) with ESMTP ID MG00095A;
   6 Apr 2009 09:17:31 -0400
From: <corbettk@[domain]>
Organization: Bradford County
To: smithm@[domain]
Date: Mon, 06 Apr 2009 09:17:30 -0400
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-3972
Subject: 04-06-09 report
Subject: 04-06-09 report

I sent 2 emails to the user (smithm) from outside the domain and did

not get delivery confirmations.  I was starting to wonder if I had gone

crazy and if dilbert was right all along, but then I ran across this

example of what I keep getting:

I guess what I really want4ed to see is the headers as sent or actually received on the other end rather than this bounce.   If it possible to turn on session logging to see the actual headers of the message that was forwarded?  If there is no header like "Return-receipt-to:" in the sent message that asks for a delivery notification then my only guess is that the receiving server is setup to always send a delivery notification.

Ran a test with Pegasus and made sure read confirm and delivery confirm were checked.  I did receive the delivery confirmation, but so did he...  on both of his accounts.  Is there something misconfigured that is causing him to receive these delivery requests as well as the originator? Here is the contents of the .MS file that the session created:

14:53:47.078: Connection from 172.16.4.51, Mon Apr 06 14:53:47 2009<lf>
14:53:47.093: << 220 mail.[domain] ESMTP server ready.<cr><lf>
14:53:47.093: >> EHLO D71CP3F1<cr><lf>
14:53:47.125: << 250-mail.[domain] Hello D71CP3F1; ESMTPs are:<cr><lf>250-TIME<cr><lf>
14:53:47.125: << 250-SIZE 0<cr><lf>
14:53:47.140: << 250 HELP<cr><lf>
14:53:47.421: >> MAIL FROM:<mailtest@mail.[domain]> SIZE=627<cr><lf>
14:53:47.453: << 250 Sender and size (627) OK - send RCPTs.<cr><lf>
14:53:47.453: >> RCPT TO:<smithm@mail.[domain]><cr><lf>
14:53:47.500: << 250 Recipient OK - send RCPT or DATA.<cr><lf>
14:53:47.500: >> DATA<cr><lf>
14:53:47.515: << 354 OK, send data, end with CRLF.CRLF<cr><lf>
14:53:47.515: >> From: "External Mailtest" <mailtest@mail.[domain]><cr><lf>
14:53:47.687: >> Organization: Bradford County<cr><lf>
14:53:47.687: >> To: smithm@mail.[domain]<cr><lf>
14:53:47.687: >> Date: Mon, 6 Apr 2009 14:53:46 -0400<cr><lf>
14:53:47.703: >> MIME-Version: 1.0<cr><lf>
14:53:47.718: >> Subject: MIS Test 6<cr><lf>
14:53:47.718: >> Message-ID: <49DA177A.26273.146C225@localhost><cr><lf>
14:53:47.750: >> X-Confirm-Reading-To: "External Mailtest" <mailtest@mail.[domain]><cr><lf>
14:53:47.765: >> X-pmrqc: 1<cr><lf>
14:53:47.781: >> Return-receipt-to: "External Mailtest" <mailtest@mail.[domain]><cr><lf>
14:53:47.781: >> Priority: normal<cr><lf>
14:53:47.796: >> X-mailer: Pegasus Mail for Windows (v4.01)<cr><lf>
14:53:47.796: >> Content-type: text/plain; charset=US-ASCII<cr><lf>
14:53:47.796: >> Content-transfer-encoding: 7BIT<cr><lf>
14:53:48.812: >> Content-description: Mail message body<cr><lf>
14:53:48.812: >> <cr><lf>
14:53:48.828: >> still testing.<cr><lf>
14:53:48.828: >> .<cr><lf>
14:53:48.859: << 250 Data received OK.<cr><lf>
14:53:48.906: >> QUIT<cr><lf>
14:53:48.921: << 221 mail.[domain] Service closing channel.<cr><lf>
14:53:48.937: --- Connection closed normally at Mon Apr 06 14:53:48 2009. ---
14:53:48.953: 

Ran a test with Pegasus and made sure read confirm and delivery confirm were checked.

This again is the inbound message.  What we need to see is the outbound message sent by Mercury/32 via the forwarding.  This would be shown in a MercuryC or MercuryE session log.

I turned on session logging and verbose general logging for MercuryE.  MercuryC is not enabled as a protocol.  I have sent a couple of tests and have verified the delivery confirmations are being generated, yet no session file exists in the MercuryE sessions for either the test mail or the delivery confirmations.

As a test, I just sent two test mails through.  One with delivery confirmation on, one with it off.  Neither mail generates a session file thru MercuryE.  The mail with asking for delivery confirmation generated confirmations wherever it hit (my account received confirmation, his main account received confirmation, and the mobile account received confirmation).  The mail not asking for confirmation generated no confirmations.

[quote user="ryanj"]As a test, I just sent two test mails through.  One with delivery confirmation on, one with it off.  Neither mail generates a session file thru MercuryE.

The mail with asking for delivery confirmation generated confirmations wherever it hit (my account received confirmation, his main account received confirmation, and the mobile account received confirmation).  The mail not asking for confirmation generated no confirmations.[/quote]

If the mail is asking for confirmations when originally sent, the basically unchanged message is going to be forwarded using a MAIL FROM that matches the original X-Delivered to: email address.  In this case the messages MAIL FROM: address will get a delivery confirmation.

This is the only mail server on the network. Just for kicks, I shut down Mercury and tried to telnet into port 25 make sure that there wasn't another rogue mailer running there, and there wasn't.  

 All three accounts in question (mailtest, smith and smithmobile) are all user accounts on the same mail server.  I send a test message, I can see said message show up in MercuryS session log, and then I get nothing on MercuryS or MercuryE sessions as far as the delivery notification messages that get generated and delivered. I don't know what else could be handling the notifications, but I can't find a trace of them in Mercury logs, which is odd since it's a Mercury generated message.

I'm flummoxed.  I still can't find a reason for this. I guess my next step is to fire up Wireshark and start sniffing packets, hoping that the notification messages run across a network interface.

[quote user="ryanj"]All three accounts in question (mailtest, smith and smithmobile) are all user accounts on the same mail server.  I send a test message, I can see said message show up in MercuryS session log, and then I get nothing on MercuryS or MercuryE sessions as far as the delivery notification messages that get generated and delivered. I don't know what else could be handling the notifications, but I can't find a trace of them in Mercury logs, which is odd since it's a Mercury generated message.[/quote]

When you send an SMTP message, MercS accepts the message (and logs it as per your settings) which is then passed to Core for processing.

Core determines if the recipient is local or non-local, and either delivers it to the local users maildrop or passes it to the SMTP client module (MercE or MercC) for external delivery.

If the "Return-Receipt-To:" header is present, Core will generate a Delivery Notification with a MAIL FROM: <> and RCPT TO: the original MAIL FROM: address (so MercS is not involved in this) and either deliver it locally or pass it to the SMTP client for external delivery. These will show in the Core Process window but will not be in the system log.

Thanks for that.

 It still doesn't explain why when I request delivery notification, every address involved gets one.  Today I am going to include an additional external address into his FORWARD file to try to catch a session on MercuryE.  To my way of thinking, only one delivery confirmation should be generated, and that confirmation should go to the originating mailbox.  Instead I wind up with a trail of confirmations for some reason.

I added the external address, which in no way should be receiving a delivery confirmation, and yet it was sent.  Just to be clear, I originated the message with a confirmation request from mailtest@domain.com, sending to smithm@domain.com.  In smithm's FORWARD file were two addresses: marksmobile@domain.com and generic@gmail.com. The Deliver-Also: flag was set to Y.

All mailboxes involved received a delivery confirmation.  Here is the MercuryE session captured as it sent confirmation to gmail:

09:28:28.718: --- Wed Apr 08 09:28:28 2009 ---
09:28:28.750: Connect to '209.85.221.90', timeout 60.
09:28:29.781: >> 220 *************************************<cr><lf>
09:28:29.812: << EHLO domain.com<cr><lf>
09:28:29.875: >> 250-mx.google.com at your service, [209.74.46.165]<cr><lf>
09:28:29.890: >> 250-SIZE 35651584<cr><lf>
09:28:29.921: >> 250-8BITMIME<cr><lf>
09:28:29.953: >> 250-ENHANCEDSTATUSCODES<cr><lf>
09:28:29.984: >> 250 PIPELINING<cr><lf>
09:28:29.093: << MAIL FROM:<smithm@domain.com> SIZE=1515<cr><lf>
09:28:29.171: >> 250 2.1.0 OK 30si7794372qyk.13<cr><lf>
09:28:30.281: << RCPT TO:<generic@gmail.com><cr><lf>
09:28:30.921: >> 250 2.1.5 OK 30si7794372qyk.13<cr><lf>
09:28:30.000: << DATA<cr><lf>
09:28:30.046: >> 354  Go ahead 30si7794372qyk.13<cr><lf>
09:28:32.671: << Received: from Spooler by domain.com (Mercury/32 v4.51) ID MO000024;<cr><lf>    8 Apr 2009 09:28:30 -0400<cr><lf>
09:28:32.703: << Received: from spooler by domain.com (Mercury/32 v4.51); 8 Apr 2009 09:28:19 -0400<cr><lf>
09:28:32.718: << Received: from spooler by domain.com (Mercury/32 v4.51)<cr><lf>
09:28:32.734: <<   for <smithm@domain.com>;  8 Apr 2009 09:28:08 -0400<cr><lf>
09:28:32.734: << Resent-from: smithm@domain.com<cr><lf>
09:28:34.687: << Resent-Date: Wed, 8 Apr 2009 09:28:08 -0400<cr><lf>
09:28:34.687: << X-Autoforward: 1<cr><lf>
09:28:34.703: << From:    Mail Delivery System <postmaster@domain.com><cr><lf>
09:28:34.734: << To:      smithm@domain.com<cr><lf>
09:28:35.687: << Date:    Wed, 8 Apr 2009 09:27:55 -0400<cr><lf>
09:28:35.703: << Subject: Delivery Confirmation<cr><lf>
09:28:35.734: << Message-ID: <17921E315897@domain.com><cr><lf>
09:28:38.703: << <cr><lf>
09:28:38.718: << With reference to your message with the subject:<cr><lf>
09:28:47.000: <<    "MIS Test 14"<cr><lf>
09:28:52.000: << <cr><lf>
09:28:59.000: << Your message was successfully delivered to the following addresses:<cr><lf>
09:29:00.703: <<    marksmobile@domain.com<cr><lf>
09:29:00.734: << <cr><lf>
09:29:05.031: << <cr><lf>
09:29:13.375: << ------------------ Beginning of message follows --------------------<cr><lf>
09:29:13.390: << <cr><lf>
09:29:13.421: << Received: from spooler by domain.com (Mercury/32 v4.51)<cr><lf>
09:29:14.406: <<   for <smithm@domain.com>;  8 Apr 2009 09:27:39 -0400<cr><lf>
09:29:18.375: << Resent-from: smithm@domain.com<cr><lf>
09:29:18.390: << Resent-Date: Wed, 8 Apr 2009 09:27:39 -0400<cr><lf>
09:29:19.406: << X-Autoforward: 1<cr><lf>
09:29:20.390: << Return-path: <mailtest@domain.com> <cr><lf>
09:29:20.421: << Received: from D71CP3F1 (172.16.4.51) by domain.com (Mercury/32 v4.51) with ESMTP ID MG00001D;<cr><lf>
09:29:23.375: <<    8 Apr 2009 09:27:32 -0400<cr><lf>
09:29:23.390: << From: "External Mailtest" <mailtest@domain.com><cr><lf>
09:29:23.421: << Organization: Bradford County<cr><lf>
09:29:26.390: << To: smithm@domain.com<cr><lf>
09:29:26.406: << Date: Wed, 8 Apr 2009 09:27:17 -0400<cr><lf>
09:29:29.359: << MIME-Version: 1.0<cr><lf>
09:29:29.390: << Subject: MIS Test 14<cr><lf>
09:29:37.000: << Message-ID: <49DC6DF5.15956.A688D2E@localhost><cr><lf>
09:29:42.000: << Message-ID: <49DC6DF5.15956.A688D2E@localhost><cr><lf>
09:29:47.000: << <cr><lf>
09:29:54.000: << .<cr><lf>
09:30:00.468: >> 250 2.0.0 OK 1239197400 30si7794372qyk.13<cr><lf>
09:30:00.609: << QUIT<cr><lf>
09:30:00.156: >> 221 2.0.0 closing connection 30si7794372qyk.13<cr><lf>
09:30:00.218: --- Connection closed normally at Wed Apr 08 09:30:00 2009. ---
09:30:00.265: 
 

I've just tried a similar setup on my 4.62 server and I get different results:  Local sender A send to local user B who has forwarding to C.  Only A gets confirmation of delivery.  Assuming you don't have any strange filters interfering, is it possible to upgrade ?

I will push my boss to allow an upgrade tonight, and hope that this issue does not follow.  Boss gave the thumbs-up as I was typing, in fact.

Does anyone know off the top of their heads if the site-wide license we have for 4.51 will roll over to 4.62?  I'll start looking over the license agreement if I don't hear back before I get my stuff around to start the upgrade.

Thanks

 [EDIT] I just checked the filtering rules and there is nothing in there, so I'm keeping my fingers crossed.

Does anyone know off the top of their heads if the site-wide license we

have for 4.51 will roll over to 4.62?  I'll start looking over the

license agreement if I don't hear back before I get my stuff around to

start the upgrade.

Oh sweet irony: The user who has been affected by this (my boss's boss) is working late tonight and will not let me do the upgrade this evening.

Thanks for the info on the licensing.  I will put the results of the upgrade in this thread once cruel, cruel fate stops toying with me.