You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Hontvari Jozsef <ho...@solware.com> on 2003/06/30 12:45:12 UTC
sender, from, returnPath
Another idea for AbstractRedirect:
Currently the envelope sender and the from address come from a single config
parameter. Two examples which show that a separate config parameter would be
better:
1. bounce letter: envelope sender is <>, from address is
MAILER-DAEMON@xxx.com
2. checked bounce letter: envelope sender is return-john=xxx.com@yyy.com,
from address is <jo...@zzz.com>
I don't know much about returnPath, but it may be related.
(A further enhancement, would be to add a fromName parameter in addition to
the fromAddress. The resulting from header is something like "John
<jo...@xxx.com>". But fromName is more difficult, it may require charset
information. So I don't say that we should add it immediately, but it may
affect the naming of config parameters)
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: sender, from, returnPath
Posted by Hontvari Jozsef <ho...@solware.com>.
Vincenzo,
>BTW, have you had the time to try my last commit (this morning) to
AbstractRedirect & subclasses, that includes your patch among other things?
I had no chance to try it yet, tomorrow I'll set it up. Currently I am
running the yesterday CVS version + my patch.
----- Original Message -----
From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, June 30, 2003 3:05 PM
Subject: RE: sender, from, returnPath
Joszef,
> Another idea for AbstractRedirect:
>
> Currently the envelope sender and the from address come from a
> single config
> parameter. Two examples which show that a separate config
> parameter would be
> better:
> 1. bounce letter: envelope sender is <>, from address is
> MAILER-DAEMON@xxx.com
> 2. checked bounce letter: envelope sender is return-john=xxx.com@yyy.com,
> from address is <jo...@zzz.com>
>
> I don't know much about returnPath, but it may be related.
>
It is related, although is a different thing.
In RFC 2821:
<snippet>
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent.
</snippet>
In RFC 2822:
<snippet>
3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
</snippet>
It seems that adding a way to handle a <from> different from <sender> could
be useful more for applications (showing an "apparent" from more complex
than a single simple address as supported currently) than for administrator
needs (config.xml); we can think at it later on for completeness, but I
suggest for the moment to consolidate AbstractRedirect & subclasses.
Reading the RFC it comes to my mind the fact that, if we implement a <from>
parameter, we would need to choose whether to keep it independent from
<sender>, i.e. leaving up to the coder of the configuration file the
responsibility to follow the rules specified in the RFC, or do it
automatically (handling defaults): same discussion we had about <recipients>
vs <to> in Redirect, that made us end up creating a new "Resend" mailet.
In fact, to this respect, I started to deprecate myself Redirect; I'm now
considering Resend as the "fully" controllable redirection mailet, and
Redirect as the one with "smart" defaults: IMO we should keep this
distinction consistent (and well documented).
> (A further enhancement, would be to add a fromName parameter in
> addition to
> the fromAddress. The resulting from header is something like "John
> <jo...@xxx.com>". But fromName is more difficult, it may require charset
> information. So I don't say that we should add it immediately, but it may
> affect the naming of config parameters)
I too was thinking at this possibility; but based on the previous point I
would use a <from> parameter to hold any "sender" information that differs
from a single simple address (john@xxx.com), so your point would fall into
the <from> support, that allows also for using multiple senders. But again
defaults would be critical.
BTW, have you had the time to try my last commit (this morning) to
AbstractRedirect & subclasses, that includes your patch among other things?
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: sender, from, returnPath
Posted by "Noel J. Bergman" <no...@devtech.com>.
These are different things. The confusion is that the term "sender" is
overloaded in common parlance and some APIs, but the RFCs use unambiguous
terms. The Return-Path header (aka "envelope-from", Mail.set|getSender,
mail.smtp.from) comes from what the RFC calls the reverse-path.
Consider the headers for the message I am replying to:
Return-Path: <ja...@jakarta.apache.org>
Received: from apache.org (daedalus.apache.org [208.185.179.12])
by ziggy.conterra.com (8.12.8/8.12.8) with SMTP id h5UD5RWq046011
for <no...@devtech.com>; Mon, 30 Jun 2003 09:05:27 -0400 (EDT)
(envelope-from
james-dev-return-9556-noel=devtech.com@jakarta.apache.org)
Reply-To: "James Developers List" <ja...@jakarta.apache.org>
From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
To: "James Developers List" <ja...@jakarta.apache.org>
These are described in:
Return-Path: header, but records MAIL FROM <reverse-path>, RFC 2821
Reply-To: header, RFC 2822 3.6.2
From: header, RFC 2822 3.6.2
See also:
Sender: header, RFC 2822 3.6.2]
The confusion about "sender" often comes from using it to refer to something
other than the "Sender:" header, which is different from the parameter given
to "MAIL FROM" *and* different from the "From:" header. The Return-Path
header records the "reverse-path", which you can see in RFC 2821 3.3:
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
The <reverse-path> portion of the first or only argument
contains the source mailbox (between "<" and ">" brackets),
which can be used to report errors (see section 4.2 for a
discussion of error reporting).
RFC 2821 4.1.1.2 elaborates:
"MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF
Finally, RFC 2821 4.4 introduces the "Return-Path" header:
The return-path line preserves the information in the <reverse-
path> from the MAIL command.
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent.
Also, see http://cr.yp.to/proto/verp.txt, which discusses an important use
of the reverse-path.
This confusion appears to still be present in the new code. Look at
setSender, which sets both the From header and the reverse path to the
passed value. Those are separate issues.
I would suggest that we clean up this area in AbstractRedirect, and document
how each element relates to the RFCs.
--- Noel
-----Original Message-----
From: Vincenzo Gianferrari Pini [mailto:vincenzo.gianferraripini@praxis.it]
Sent: Monday, June 30, 2003 9:06
To: James Developers List
Subject: RE: sender, from, returnPath
Joszef,
> Another idea for AbstractRedirect:
>
> Currently the envelope sender and the from address come from a
> single config
> parameter. Two examples which show that a separate config
> parameter would be
> better:
> 1. bounce letter: envelope sender is <>, from address is
> MAILER-DAEMON@xxx.com
> 2. checked bounce letter: envelope sender is return-john=xxx.com@yyy.com,
> from address is <jo...@zzz.com>
>
> I don't know much about returnPath, but it may be related.
>
It is related, although is a different thing.
In RFC 2821:
<snippet>
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent.
</snippet>
In RFC 2822:
<snippet>
3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
</snippet>
It seems that adding a way to handle a <from> different from <sender> could
be useful more for applications (showing an "apparent" from more complex
than a single simple address as supported currently) than for administrator
needs (config.xml); we can think at it later on for completeness, but I
suggest for the moment to consolidate AbstractRedirect & subclasses.
Reading the RFC it comes to my mind the fact that, if we implement a <from>
parameter, we would need to choose whether to keep it independent from
<sender>, i.e. leaving up to the coder of the configuration file the
responsibility to follow the rules specified in the RFC, or do it
automatically (handling defaults): same discussion we had about <recipients>
vs <to> in Redirect, that made us end up creating a new "Resend" mailet.
In fact, to this respect, I started to deprecate myself Redirect; I'm now
considering Resend as the "fully" controllable redirection mailet, and
Redirect as the one with "smart" defaults: IMO we should keep this
distinction consistent (and well documented).
> (A further enhancement, would be to add a fromName parameter in
> addition to
> the fromAddress. The resulting from header is something like "John
> <jo...@xxx.com>". But fromName is more difficult, it may require charset
> information. So I don't say that we should add it immediately, but it may
> affect the naming of config parameters)
I too was thinking at this possibility; but based on the previous point I
would use a <from> parameter to hold any "sender" information that differs
from a single simple address (john@xxx.com), so your point would fall into
the <from> support, that allows also for using multiple senders. But again
defaults would be critical.
BTW, have you had the time to try my last commit (this morning) to
AbstractRedirect & subclasses, that includes your patch among other things?
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: sender, from, returnPath
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Joszef,
> Another idea for AbstractRedirect:
>
> Currently the envelope sender and the from address come from a
> single config
> parameter. Two examples which show that a separate config
> parameter would be
> better:
> 1. bounce letter: envelope sender is <>, from address is
> MAILER-DAEMON@xxx.com
> 2. checked bounce letter: envelope sender is return-john=xxx.com@yyy.com,
> from address is <jo...@zzz.com>
>
> I don't know much about returnPath, but it may be related.
>
It is related, although is a different thing.
In RFC 2821:
<snippet>
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent.
</snippet>
In RFC 2822:
<snippet>
3.6.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more mailbox specifications. If the
from field contains more than one mailbox specification in the
mailbox-list, then the sender field, containing the field name
"Sender" and a single mailbox specification, MUST appear in the
message. In either case, an optional reply-to field MAY also be
included, which contains the field name "Reply-To" and a
comma-separated list of one or more addresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
</snippet>
It seems that adding a way to handle a <from> different from <sender> could be useful more for applications (showing an "apparent" from more complex than a single simple address as supported currently) than for administrator needs (config.xml); we can think at it later on for completeness, but I suggest for the moment to consolidate AbstractRedirect & subclasses.
Reading the RFC it comes to my mind the fact that, if we implement a <from> parameter, we would need to choose whether to keep it independent from <sender>, i.e. leaving up to the coder of the configuration file the responsibility to follow the rules specified in the RFC, or do it automatically (handling defaults): same discussion we had about <recipients> vs <to> in Redirect, that made us end up creating a new "Resend" mailet.
In fact, to this respect, I started to deprecate myself Redirect; I'm now considering Resend as the "fully" controllable redirection mailet, and Redirect as the one with "smart" defaults: IMO we should keep this distinction consistent (and well documented).
> (A further enhancement, would be to add a fromName parameter in
> addition to
> the fromAddress. The resulting from header is something like "John
> <jo...@xxx.com>". But fromName is more difficult, it may require charset
> information. So I don't say that we should add it immediately, but it may
> affect the naming of config parameters)
I too was thinking at this possibility; but based on the previous point I would use a <from> parameter to hold any "sender" information that differs from a single simple address (john@xxx.com), so your point would fall into the <from> support, that allows also for using multiple senders. But again defaults would be critical.
BTW, have you had the time to try my last commit (this morning) to AbstractRedirect & subclasses, that includes your patch among other things?
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org