Hello!
Thursday, March 16, 2000, 2:43, Michael Wieczorek <[EMAIL PROTECTED]>
wrote:
<lost>
AVK>> ...and Stefan is right (as always;-)) here: you should *not* set
AVK>> the return-path yourself, on the user side you should limit
AVK>> yourself to altering the Reply-To: header... because return-path:
AVK>> is subject to be set/changed/altered by the SMTP server...
^^^^^^^^^^^^^^^ Take a look at these words.
MW> But the "Return-Path:" is setting by *TB* to the "Reply-To:"-address
MW> *not* by the server.
See my note above. It's a server's deal to _operate_ with this header.
Do you know that Return-Path isn't limited only to the [EMAIL PROTECTED]
form? Here's some sample for you:
Return-Path: sunny.aha.ru!apache.org!apache-announce-owner
MW> If I right to understand the RFC-822 (see below), the RFC
MW> means that the "Return-Path" is used to identify the _originator_.
It's intended to provide an addressing information about originator and,
in some cases, the back route for message originator, for example, in
UUCP form.
MW> That means for me: the _send-address_ not the reply-address.
MW> Explanation to above: [EMAIL PROTECTED] is my send address, [EMAIL PROTECTED]
MW> is my reply-address. But the header generated by TB looks like
MW> Return-Path: <[EMAIL PROTECTED]>
MW> Date: Tue, 14 Mar 2000 21:09:46 +0100
MW> From: Michael Wieczorek <[EMAIL PROTECTED]>
MW> X-Mailer: The Bat! (v1.41) Personal
MW> Reply-To: [EMAIL PROTECTED]
MW> Organization: home sweet home
MW> X-Priority: 3 (Normal)
MW> Message-ID: <[EMAIL PROTECTED]>
MW> To: [EMAIL PROTECTED]
MW> Subject: test mit re nach gmx
MW> Mime-Version: 1.0
MW> Content-Type: text/plain; charset=ISO-8859-1
MW> Content-Transfer-Encoding: 8bit
MW> RFC-822
MW> [..]
MW> 4.3.1. RETURN-PATH
MW> This field is added by the final transport system that
MW> delivers the message to its recipient. The field is intended
MW> to contain definitive information about the address and route
MW> back to the message's originator.
This is the key words.
<lost>
MW> Note: The "Return-Path" field is added by the mail transport
MW> service, at the time of final deliver. It is intended
MW> to identify a path back to the orginator of the mes-
MW> sage.
And this is too.
MW> So I think it is a bug by TB, is'nt it?
No.
X-TheBat-Version: 1.41
X-OS: Windows 95 4.0.1111 B PE
X-System-Info: iP-III-500/128
--
Best regards, mailto:[EMAIL PROTECTED]
Andrey G. Sergeev (AKA Andris) http://www.andris.msk.ru/
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : [email protected]
Re: Using Macros for header (%RETURNPATH="...")
Andrey G. Sergeev (AKA Andris) Wed, 15 Mar 2000 16:17:01 -0800
- Using Macros for header (%RETURNPATH="... Michael Wieczorek
- Re: Using Macros for header (%RETURNPA... Thomas Fernandez
- Re: Using Macros for header (%RETURNPA... Stefan Tanurkov
- Re: Using Macros for header (%RETU... Alexander V. Kiselev
- Re: Using Macros for header (%... Michael Wieczorek
- Re: Using Macros for heade... Andrey G. Sergeev (AKA Andris)
- Re: Using Macros for heade... Alexander V. Kiselev
- Re: Using Macros for ... Michael Wieczorek
- uuups Sorry - wro... Michael Wieczorek
- Re: Using Macros for ... Michael Wieczorek
- Re: Using Macros ... Andrey G. Sergeev (AKA Andris)
- Re: Using Mac... Alexander V. Kiselev
- Re: Using Macros ... Alexander V. Kiselev
- Re: Using Mac... Dieter Hummel
- Re: Using Mac... Michael Wieczorek
- Re: Using Mac... Michael Heydekamp

