How to handle Return-Path

Each email sent is put into an "envelope" and sent to the SMTP port. That envelope contains a few simple commands as well as the data and headers you had constructed. When the "MAIL FROM: " command is inserted into the email "envelope" , the qmail program will silently insert the "Return-Path: " header to the same email address that "MAIL FROM: " is indicating before being sent over the net. The "Return-Path: " address is what is used by most servers to bounce back the email, if the email address was incorrect. You cannot spoof that "Return-path: " header by inserting one of yours while constructing the email header in your Rebol app. This is because the one created by qmail would be right on top of the rest of the header members, and other email servers would read that path and ignore other occurances of "Return-path: " in the same header. When I investigated the Rebol-SDK source (prot_send.r) I found that Return-Path is not handled at all. The "MAIL FROM: " is always pointing to the "From: " member of the email header object. That is not correct. This is the patch that did the trick: I commented out all occurances (there are two) of the following statement : do-send smtp-port ["MAIL FROM: <" from ">"] and I replaced it by a call to an internal local function which has 3 arguments : sendProperFrom header-Obj smtp-port from The function is written as follows: sendProperFrom: func [hObj s-port frm ] [ either get in hObj 'Return-Path [ do-send s-port ["MAIL FROM: <" hObj/Return-Path ">"] hObj/Return-Path: none ] [ do-send s-port ["MAIL FROM: <"from ">"] ] ] Note that the above is a local function within the "send" func. After the above patch, the send function works properly. Whenever I want to give a separate "Return-Path" which is different from the "From: " address, then I would specify that as the value of a email header member "Return-Path: " At the same time, when such an email is received at the other end, the email client will be indicating that it orginated from the "From: " address I hope this is of use. I have tested this only using qmail. Maybe Ingo Hohmann can integrate this patch into the patched "send" function he is developing. If there are any other caveats I should watch out, then please do let me know. Regards Sabu Francis

Thank you for sharing your findings. Very useful information to know. Regards, Brett.

<..> Just to mention it, mine is not the only one, just the most aggressively advertized ;-) I will definitely have a look at it for the next round of updates. Thank you, Ingo