RE: IsPersonallySent (was AbstractRedirect family: Reply-To handling)

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

Jozsef ,

In fact my IsPersonallySent and IsImpersonallySent matchers were written to catch also false virus bounces etc. The general logic is to have a list of "or-ed" rules, each one of them excluding that a message is *personally* sent plus a set of "and-ed" rules required to state that it is personally sent. By personally I mean somebody (not a bot) has "physically" (conciously) and personally sent a message to the recipient and not through a list etc. My goal was to do a "selective" auto-responding, but there could be different purposes.

Regarding rule (vi), by "postmaster" I mean the result of getMailetContext().getPostmaster(): the local James postmaster. Looking for various strings that could represent an outside postmaster sender, like MAILER-DAEMON[@...] or postmaster[@...] would be another rule. Which strings? Should we use condition strings / init parameters with additional regex criteria?

Regarding rule (viii) "the recipient is listed in the To header", you are right, if the user forwards an account this will give a false indication: it would be a false negative for IsPersonallySent and a false positive for IsImpersonallySent. But my goal was to be conservative doing auto-responding.

Regarding rule (ix) "the recipient != from the reversePath", I didn't want to auto-respond to "self". I noticed also that some virus and spammers send messages with the reversePath set same as the recipient.

The rules are "heuristic", and probably can never be complete, so that false positives and false negatives will always appear: same problem as with spam filtering.

If you are interested, I can send you the two matchers. As said in my previous message in this thread, this logic could be inserted in a new AutoResponder mailet, but could  also be useful as standalone matchers.

Any other thoughts? Are there any other rules that could make sense? Is there interest for having this stuff made available?

Vincenzo

> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: giovedì 4 settembre 2003 9.20
> To: James Developers List
> Subject: Re: AbstractRedirect family: Reply-To handling
> 
> 
> 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" <vi...@praxis.it>
> To: "James Developers List" <se...@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
> 


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