[ZendTo] Re: Return-Path change

[Brad Beckenhauer]

I was looking at this same issue yesterday, but ran out of time.
 
a snip from the web on the Return-Path
 
Envelope information: Return-Path, Received
Return-Path
The value of a Return-Path field is tokenizable. It shows the return path of the message, i.e., the address that bounces will be sent to. It is either (1) a < token followed by a > token, indicating an empty return path, or (2) a bracketed address. Two examples:
 
     Return-Path: <>
     Return-Path: <God at heaven.af.mil>
 
Messages transmitted through SMTP generally do not have Return-Path fields; the return path is transmitted out-of-band in the SMTP MAIL request. When a message is stored in a mailbox, the return path is stored in a Return-Path field. If the message is then retrieved (e.g., through POP) and sent through another SMTP hop, the Return-Path is removed and the return path is again sent out-of-band. 
 
 
I'm pretty sure the function calling it is in the lib/NSSDropbox file, but have not figured out exactly how to add the coding.
 
I'll be watching this thread.
Brad
 
 


>>> On 9/21/2010 at 2:44 PM, in message <9453A32CAC9FFB4D8F59285E34B6A50604AD27 at hotc_exch.harperotc.com>, "Naz Snidanko" <nsnidanko at harperpowerproducts.com> wrote:


Hi, ZendTo Users
Scenario:
User creates dropoff but misspells email address. MTA tries to deliver but domain has no MX record, so it generates bounce-back email sent to Return-Path: header value, which goes nowhere (www-data at server.domain.com in my case) and thus it creates confusion 
How can I change Return-Path: header value for an email address of the person that created dropoff? To either From or Reply-To? Tis way person will get bounce back message and correct his mistake.
Please advice,

Naz Snidanko
Desktop & Network Support
Harper Power Products Inc.
(p) 416 201- 7506
nsnidanko at harperpowerproducts.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20100921/20dab92b/attachment.html