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: AbstractRedirect family: Reply-To handling
Date Thu, 04 Sep 2003 07:19:58 GMT
IsImpersonallySent matcher could also be really useful for a different
purpose, filtering out false virus bounces coming to an innocent email
address.

>(vi) the sender is not the postmaster and

and not a MAILER-DAEMON[@...]

>(viii) the recipient is listed in the To header and

if the user forwards an account this will give a false indication

>(ix) the recipient != from the reversePath.

Could you explain this?

+I see some mail headers in bounces and auto-replies, which are obvious
indicators of non-personal mails. But I have no more precise information
this.

----- Original Message ----- 
From: "Vincenzo Gianferrari Pini" <vincenzo.gianferraripini@praxis.it>
To: "James Developers List" <server-dev@james.apache.org>
Sent: Wednesday, September 03, 2003 4:29 PM
Subject: RE: AbstractRedirect family: Reply-To handling


I just committed an update to AbstractRedirect, Redirect and Resend to
handle a new "replyTo" value that can be used in the <recipients> and <to>
parameters (and/or returned by getRecipients() and getTo() in subclasses.
The behaviour is as specified in RFC 2822: Reply-To defaulting to From
defaulting to Sender. I made the extension of having Sender defaulting to
Return-Path instead of null.

A simple auto-responder behaviour can now be done using either Redirect or
Resend.

I'm asking myself if NotifySender should be modified to notify to the
Reply-To address.

Regarding a full auto-responder mailet, still to be done, I suggest the
following subclassing:

AbstractRedirect
AutoResponder
DynamicAutoResponder (or any other name)

The AutoResponder mailet would have a fixed "respond" message <message> and
could be activated using the RecipientIs matcher (or any other matching
logic); the DynamicAutoResponder mailet should instead be based on a table
of user_name/message_text/activation_flag. A user could then send a message
to auto.responder@xyz.com with subject "on" or "off" and message text
containing the personal "respond" message.

IMO an important thing that should not be forgotten in the AutoResponder
mailet is the following: not any message should be replied to, but only
those whose sender is "not impersonal". For example, if I auto-respond to
this list (server-dev@james.apache.org), my understanding is that
automatically the "list manager" would send a probe and, after another
auto-respond, I would be kicked off the list.

As this summer I had to set up a "manual" auto-respond mechanism in
config.xml for some colleagues in my company, I wrote a matcher
("IsImpersonallySent") that was trying to deal with that. It had the
following rules:

A mail is personally sent to a recipient if
(i) has a non null reversePath and
(ii) has a non null From header and
(iii) the From header has only one address and
(iv) the From header address equals the reversePath and
(v) the ReplyTo header address (if any) equals the reversePath and
(vi) the sender is not the postmaster and
(vii) has a non null To header and
(viii) the recipient is listed in the To header and
(ix) the recipient != from the reversePath.

I'm not sure at all about those rules, but we should discuss about this
topic before writing a "full" auto-responder mailet.

Vincenzo

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: giovedi 28 agosto 2003 10.15
> To: James-Dev Mailing List
> Subject: AbstractRedirect family: Reply-To handling
>
>
> For the getRecipients, the default behavior is documented by RFC (2)2822.
> It says that when sending a response, e.g., an auto-responder not
> a bounce,
> the default behavior should be the Reply-To: header(s).  If they don't
> exist, the From: header(s) should be used.
>
> See: RFC 822 section 4.4.4 and RFC 2822 section 3.6.2.
>
> Vincenzo, do you have time to look at this?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message