RE: Newsgroup integration, and other questions

[Jeff Keyser]

Actually, the problem isn't that James needs to lookup MX records as much as
it is that James doesn't know what DNS servers the local host was configured
to use.  If James could read the DNS configuration of the local machine,
this wouldn't need to be set again in the config.

> -Original Message-
> From: Chaudhuri, Hiran [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 15, 2002 5:26 PM
> To: James Developers List
> Subject: RE: Newsgroup integration, and other questions
>
>
> Hi, Danny.
>
> Thank you for that explanation. Yes, I was no longer aware of those MX
> records that need to be queried. What I thought of was only
> the hostname
> that might need resolution.
>
> Hiran
>
> -
> Hiran Chaudhuri
> SAG Systemhaus GmbH
> Elsenheimerstraße 11
> 80687 München
> Germany
> [EMAIL PROTECTED]
> Phone +49-89-54742-134
> Fax   +49-6151-9234-5134
>
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 15, 2002 10:56 AM
> > To: James Developers List
> > Subject: RE: Newsgroup integration, and other questions
> >
> >
> > Hiran
> >
> > > So why does a MTA by itself need to know the DNS server's ip
> > > addresses? BTW,
> > > I never entered such information and did not see any problems.
> >
> > MTA's use MX records to find a list of all MTA's to whom they
> > could deliver
> > mail for a specified domain.
> > If this list isn't found, or all of those hosts cannot be
> > contacted the MTA
> > can try to deliver directly to the domain of the address.
> >
> > Thus most mail domains actually map to servers whos name is
> > different to the
> > mail domain, in which case no DNS prevents this being delivered.
> > Some mail is correctly delivered directly to the domain.
> >
> > Java doesn't (AFAIK) have a simple method of determining MX
> > record lists or
> > the nameservers from OS network config, and local name resolution
> > (etc/hosts) doesnt contain MX information. Therefore James
> > needs to know the
> > IP of a nameserver from which it can get MX records.
> >
> > Sendmail can find the nameservers from OS config, so you
> don't have to
> > configure this parameter for it, but it isn't as portable as James.
> > Likewise, I expect, for other platform specific MTA's.
> >
> > If Java does have a way of getting lists of MX records
> > without knowing DNS
> > addresses do let us know about it.
> >
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Fwd: Re: Mailet API]

[Jeff Keyser]

I agree that the work of matching and doing something should be separate.
However, I'd like to suggest an alternative way of communicating, since it
may be helpful for a Mailet to know what parameters were user by the
Matcher.

I'm thinking specifically about the CommandForListserv Matcher and the
AvalonListservManager Mailet.  It would probably be helpful for the Mailet
to explicitly know which mailing list it is processing for.  It may also be
helpful to know which command was matched, but that's getting even more
complicated.

How to do this?  I'm not sure, but if it can be done cleanly, I see it being
useful.

> -Original Message-
> From: Andrew Timberlake [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: [Fwd: Re: Mailet API]
>
>
> Thanks Dave for the response
> I'm forwarding this thread back into the list as I would like to hear
> the main developers, and others, feedback and insight into this.
>
> Thanks
>
> Andrew
>
> -Forwarded Message-
>
> From: Dave Morris <[EMAIL PROTECTED]>
> To: Andrew Timberlake <[EMAIL PROTECTED]>
> Subject: Re: Mailet API
> Date: 22 Apr 2002 16:19:22 +0100
>
> Yep.
> Quite true.
> However, kind of makes the Matcher redundant if all the
> Mailets start doing their
> own matching.
>
> I kind of like the separation of functionality, a Matcher
> filters the messages
> and a Mailet does stuff with the messages. What I want to add
> is a way of the
> Mailet an Matcher to talk to each other, mainly to share configuration
> information.
>
> This came up when I was experimenting with designing some of
> my own custom
> Mailets.
> In each case, the Mailet needed to process emails to one or
> more addresses in a
> list or group.
> Both the Mailet and Matcher needed to be configured to access
> the same list of
> addresses.
>
> I kept ending up with an odd situation where both the Mailet
> and Matcher share
> the same list of addresses, but they can't communicate
> directly with each other.
>
> Much like the current RecipientIsLocal Matcher and
> LocalDeliver Mailet, both have
> to use an Avalon lookup to get a reference to the local
> reporistory, but they
> can't talk to each other.
>
> You are right, it is possible to implement using the current
> API, just a few
> extra hoops to jump through.
> The proposed change would just make it a little easier to
> design Matcher and
> Mailet combinations.
> If it causes too many side effects, then it isn't worth it.
>
> Thanks,
> Dave
>
>
> Andrew Timberlake wrote:
>
> > Just a quick question.
> > A mailet can perform the function of a matcher just by virtue of
> > checking the mail message as it processes it. Therefore
> could you not
> > achieve what you are looking for with the match="ALL" and then write
> > "matching" information into the mailet?
> >
> > Andrew
> >
> > On Mon, 2002-04-22 at 14:21, Dave Morris wrote:
> > > Hi,
> > >
> > > I would like to propose a change to the Mailet API, and would be
> > > interested in thoughts and ideas.
> > >
> > > At the moment, Mailets have no access to their Matcher.
> > > I appreciate that this is probably by design.
> > > However . I would like to suggest adding the
> following to the Mailet
> > > API.
> > >
> > >  /**
> > >   * Create a Matcher for this Mailet.
> > >   * Default is to return null and let the container create the
> > > Matcher.
> > >   * Advantage is that the Mailet can use it's internal data to
> > > generate and configure a suitable Matcher.
> > >   * Disadvantage is that the Mailet interface becomes
> tied to the
> > > Matcher interface.
> > >   *
> > >   */
> > >  public Matcher getMatcher() ;
> > >
> > > And changing the code which loads the Mailets and Matchers in
> > > JamesSpoolManager to this.
> > >
> > > Mailet mailet = null;
> > > Matcher matcher = null;
> > > //
> > > // Allow blank 'match' attribute in config XML.
> > > String matcherName = c.getAttribute("match", null);
> > > //
> > > // Load the Mailet.
> > > mailet = loadMailet(mailetClassName, mailetcontext, c) ;
> > > //
> > > // If the config specified a Matcher.
> > > if (null != matcherName)
> > > {
> > > matcher = loadMatcher(matcherName, mailetcontext) ;
> > > }
> > > //
> > > // If not, see if the Mailet has it's own Matcher.
> > > else {
> > > matcher = mailet.getMatcher() ;
> > > }
> > > //
> > > // If we still don't have a Matcher.
> > > if (null == matcher)
> > > {
> > > //
> > > // Two possible options.
> > > // a) Throw an Exception saying "No Matcher specified
> for Mailet".
> > > // b) Add a default 'All' Matcher.
> > > // Depends which people think makes more sense 
> > > //
> > > }
> > >
> > > This does not break any of the existing Maliets or configuration.
> > > All of the existing mailets can implement the new method
> and return
> > > nul

RE: Suggestion

[Jeff Keyser]

Oops - my bad.  From what I saw, I was under the impression that it didn't
do this.  (No apparent incoming store being my main clue.)

Sorry for not getting all my facts straight ahead of time...

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 20, 2002 2:22 PM
> To: James Developers List
> Subject: Re: Suggestion
>
>
> I'm happy to report James already does this (and actually has
> been doing
> it since day 1).  When messages are received via SMTP, James does not
> send a 250 Message received until it is written to disk.
> Then as it is
> processed, the message is not removed from the spool until it is
> successfully processed.  Pretty much no matter when you kill
> James, it
> shuld never lose a message and in certain cases duplicate a
> message if a
> processing was interrupted half way through.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
>
> Jeff Keyser wrote:
> > I would like to make a suggestion that I feel would make
> James a little more
> > robust.  (I would offer to make the change myself, but I'm
> not familiar
> > enough with the code to do this.)
> >
> > Here is the potential situation:  James receives an e-mail,
> and responds to
> > the sender that it has been received.  James then begins to
> process this new
> > e-mail, but something happens before it's done - either the computer
> > crashes, James crashes, or whatever.  This e-mail is lost,
> because the only
> > copy of it was in memory.
> >
> > What I would suggest is that James write the e-mail to a
> store while it is
> > receiving it, before it sends the final response to the
> sender.  James could
> > then use this store as its incoming e-mail queue, and
> remove e-mail from it
> > after they have been processed.  If the computer crashes
> before the e-mail
> > is written to the store, the sender never gets a final response, and
> > (theoretically) holds the e-mail to try again later.  If it crashes
> > afterwards but before processing is done, James rereads the
> e-mail from the
> > incoming queue when it restarts, and starts the processing again.
> >
> > Anyway, it's just a suggestion.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Suggestion

[Jeff Keyser]

I would like to make a suggestion that I feel would make James a little more
robust.  (I would offer to make the change myself, but I'm not familiar
enough with the code to do this.)

Here is the potential situation:  James receives an e-mail, and responds to
the sender that it has been received.  James then begins to process this new
e-mail, but something happens before it's done - either the computer
crashes, James crashes, or whatever.  This e-mail is lost, because the only
copy of it was in memory.

What I would suggest is that James write the e-mail to a store while it is
receiving it, before it sends the final response to the sender.  James could
then use this store as its incoming e-mail queue, and remove e-mail from it
after they have been processed.  If the computer crashes before the e-mail
is written to the store, the sender never gets a final response, and
(theoretically) holds the e-mail to try again later.  If it crashes
afterwards but before processing is done, James rereads the e-mail from the
incoming queue when it restarts, and starts the processing again.

Anyway, it's just a suggestion.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: New alpha release?

[Jeff Keyser]

A third fix for the next release - I have a proposed patch for the Redirect
mailet in Bugzilla waiting to be looked at.  (Not that it needs to be
implemented as-is.)

Other fixes that has been added since the last alpha (off the top of my own
head):
- the ability to load jars from the lib directory (hooray!)
- IsSenderInFakeDomain matcher doesn't match null senders anymore

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 16, 2002 5:09 PM
> To: [EMAIL PROTECTED]
> Subject: New alpha release?
>
>
> There have been a few fixes since alpha 2, the ones I
> remember off the
> top of my head include:
> - fixed delay in db repository
> - fixed pop3 dot-stuffing bug
> - fixed bounce method to use Return-Path header if there
> probably a few other fixes... hopefully people have been updating the
> changelog.xml file (hint hint).
>
> I'm almost ready to deploy a patch to better identify
> temporary delivery
> exceptions and clean up the messages a bit (like instead of saying,
> "javax.mail.SendFailedException 512 3 I don't likeyou", have
> the error
> message say, "When I tried to deliver to the mail server at
> stupid.mailserver.com, it told me: [newline]512 3 I don't likeyou".
>
> Also, I'm going to try to patch the file repository so you can save a
> message with the same message name.  I think that's the
> better fix for
> the delivery problems.  If I can't do that easily, I'll apply
> that patch
> that renames the messages when it has to store messages for replies
> (which is currently creating the 0-byte problem in the file
> repository).
>
> So, how about a vote for alpha 3 pending these 2 fixes?
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Default DNS server

[Jeff Keyser]

(Original conversation pulled from james-users list.)

I had mentioned once before that I have an OS toolkit that allows programs
to run as services/daemons.  There is another tool in the same toolkit that
reads the local machine's DNS configuration and uses Sun's JNDI/DNS provider
with that configuration.  This tool could solve this problem for you, and
may be an easy port if you're already using this provider.

http://www.jeff.keyser.name/

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 06, 2002 1:57 AM
> To: James Users List
> Subject: Re: Default DNS server
>
>
> Ah, the reason is because when you ping or telnet or use a
> webbrowser,
> you are using A and CNAME records stored in your DNS server.  When a
> mail server sends email, it uses MX records.  (A records map
> a name to
> an IP address.  CNAME map a name to another name.)
>
> The notable difference is that an MX record can have multiple entries
> for a hostname (rather than a single mapping) and include a priority.
> For example, the MX records for yahoo.com are mx2.mail.yahoo.com (1),
> mx1.mail.yahoo.com (1), and mx4.mail.yahoo.com (4).  This means mail
> servers can deliver to any of these addresses, and should
> generally try
> to deliver to mx1 or mx2 before mx4 (as indicated by the priority).
>
> So, James needs direct access to the DNS server to query MX
> records so
> it can deliver mail correctly.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
> Thomas Singer wrote:
> > Ok, Serge, I ask my question in other words: Why needs
> James the DNS
> > server setting, if Java can resolve the names automatically
> (with the
> > help of the underlying OS)?
> >
> > Tom
> >
> >
> > At 18:43 05.04.2002 -0500, you wrote:
> >
> >> Java is not using one [DNS server] itself... it is opening network
> >> connections through your operating system's network stack,
> which takes
> >> care of converting hostnames to IP addresses, establishing the
> >> connection, etc...  Java has no way of interrogating your network
> >> settings to determine what DNS server you have configured.
> >> Unfortunately you have to set this manually.  Well, I
> guess in theory
> >> we could make a DHCP request or scan the local network for a DNS
> >> server, but these both seem a bit intrusive yet convenient
> (truly a
> >> Microsoft approach).
> >> --
> >> Serge Knystautas
> >> Loki Technologies - Unstoppable Websites
> >> http://www.lokitech.com/
> >>
> >> Thomas Singer wrote:
> >>
> >>> James requires to setup the DNS server correctly.
> >>> How to tell James to use the system's DNS server (that
> one, that Java
> >>> uses itself)?
> >>> Tom
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Return-Path patch

[Jeff Keyser]

I don't think so.  When replying, you want the message to go to the sender
or what's in the "Reply-To" header.  However, bounces are not true replies,
and don't follow the same rules.

Now if there were a "bounce()" method on Message that did the same thing,
then yes, this would be a bug. :-)

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 05, 2002 12:25 AM
> To: James Developers List
> Subject: Re: Return-Path patch
>
>
> Applied patch.  You know, I'm thinking this is a bug in JavaMail...
> shouldn't the MimeMessage.reply() method take the Return-Path into
> account?  Maybe this is something only a mail server has to
> worry about.
>   Anyway, it's in CVS now.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
> Jeff Keyser wrote:
> > I apologize for sending this directly to the developer's
> list, but the bug
> > database web site isn't working at the moment.  (Or maybe I
> just can't get
> > to it from my ISP - I'm not sure which.)
> >
> > This proposed patch is in response to the repeated bounced
> e-mail from
> > lokitech.com yesterday.  The problem was that their James server was
> > bouncing the e-mail to the sender (the mailing list), and
> not the address in
> > the Return-Path header as it was supposed to.  The attached
> file is intended
> > to fix that problem.
> >
> >
> >
> --
> --
> >
> > Index: src/java/org/apache/james/James.java
> > ===
> > RCS file:
> /home/cvspublic/jakarta-james/src/java/org/apache/james/James.java,v
> > retrieving revision 1.19
> > diff -u -r1.19 James.java
> > --- src/java/org/apache/james/James.java27 Feb 2002
> 05:05:53 -1.19
> > +++ src/java/org/apache/james/James.java4 Apr 2002
> 02:19:23 -
> > @@ -347,6 +347,11 @@
> >  MimeMessage orig = mail.getMessage();
> >  //Create the reply message
> >  MimeMessage reply = (MimeMessage) orig.reply(false);
> > +//If there is a Return-Path header,
> > +if (orig.getHeader("Return-Path") != null) {
> > +//Return the message to that address, not to
> the Reply-To address
> > +
> reply.setRecipient(MimeMessage.RecipientType.TO, new
> InternetAddress(orig.getHeader("Return-Path")[0]));
> > +}
> >  //Create the list of recipients in our MailAddress format
> >  Collection recipients = new HashSet();
> >  Address addresses[] = reply.getAllRecipients();
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Return-Path patch

[Jeff Keyser]

I apologize for sending this directly to the developer's list, but the bug
database web site isn't working at the moment.  (Or maybe I just can't get
to it from my ISP - I'm not sure which.)

This proposed patch is in response to the repeated bounced e-mail from
lokitech.com yesterday.  The problem was that their James server was
bouncing the e-mail to the sender (the mailing list), and not the address in
the Return-Path header as it was supposed to.  The attached file is intended
to fix that problem.


Index: src/java/org/apache/james/James.java
===
RCS file: /home/cvspublic/jakarta-james/src/java/org/apache/james/James.java,v
retrieving revision 1.19
diff -u -r1.19 James.java
--- src/java/org/apache/james/James.java27 Feb 2002 05:05:53 -  1.19
+++ src/java/org/apache/james/James.java4 Apr 2002 02:19:23 -
@@ -347,6 +347,11 @@
 MimeMessage orig = mail.getMessage();
 //Create the reply message
 MimeMessage reply = (MimeMessage) orig.reply(false);
+//If there is a Return-Path header,
+if (orig.getHeader("Return-Path") != null) {
+//Return the message to that address, not to the Reply-To address
+reply.setRecipient(MimeMessage.RecipientType.TO, new 
+InternetAddress(orig.getHeader("Return-Path")[0]));
+}
 //Create the list of recipients in our MailAddress format
 Collection recipients = new HashSet();
 Address addresses[] = reply.getAllRecipients();



--
To unsubscribe, e-mail:   
For additional commands, e-mail: