james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hontvari Jozsef" <hontva...@solware.com>
Subject Re: sender, from, returnPath
Date Mon, 30 Jun 2003 13:29:25 GMT
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" <vincenzo.gianferraripini@praxis.it>
To: "James Developers List" <james-dev@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 <joe@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
> <john@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


Mime
View raw message