OK. Read that. Much clearer. I had forgotten the basic tenet that RCPT-TO controls routing.
So in fact, I don't need to change my MimeMessage at all because even if I do match one of the RCPT-TO's, and process it another way, in the case of the app that I am developing Istill want the downstream recipients of the message to know that the recipient that was filtered was originally sent the mail. What I do want to do is control the Mail recipients. My god. I ought to be shot!! :-) Thanks to you and Serge again... N -----Original Message----- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: 26 November 2003 14:36 To: James Users List Subject: RE: LOTS of MimeMessageWrapper issues... bugs? Importance: Low Neil, Please don't take this the wrong way, I'm about to expound on a lot of basic stuff and you probably know a lot of it already but I don't know what you know and what you don't knowso I'm just going to say it *all* and hope I don't get flamed for talking down to you... <mounts soap box> ... ;-) > The problem appears to be occurring because I am attempting to use > James as an email router that filters non local recipients. This is OK for James to do, in fact James already does this, but it can only be done effectively on mails which were routed to a recipient (local or remote) via James. Mail which James is expected to route either locally or downstream will have the destination addresses passed in in the "RCPT TO" command of the SMTP session. This is the list of recipients James must use for routing, not the message headers recipients. It will become clearer why. Our original sender, or any upstream hop from here, may have _already_ routed a copy of the message to one or more of the people mentioned in the message headers. The fact that you can see, from the headers, that this mail is also intended for a person not mentioned in the RCPT TO recipients does not in any way imply that our particular copy is bound in her direction, in fact it indicates that someone else is doing it. > My config.xml is set to deliver all local recipients (ie the RCPT-TO > recipients) This is a false assumption. The RCPT TO recipients are _all_ of the intended recipients who can be reached from here, local or remote, which James is expected to route the message to, directly or indirectly. James will, under the action of the matchers, split this RCPT TO list. In the case of the local & remote users you will end up with two copies of the message one destined for ALL the local recipients specified, the other for ALL the remote ones specified in the RCPT TO. James, in the abscence of any further matchers, would then copy the local message to each local recipient. The remote message should then be split according to the next destination server, usually on a domain by domain basis, with each copy being sent with only those recipient addresses which are judged to be reachable via a server blisted in the RCPT TO command which James issues to the (downstream) server. However it is also equally acceptable for James to send the same message multiple times to the same server with fewer than all of the appropriate recipients specified in each RCPT TO command. Think about that. It means that you could receive several copies of the same message, with the same message headers, if you deliver the message to more than only the RCPT TO recipients, because you're reading the message headers as well, you will end up delivering multiple copies. Now consider what would occur if every server in a series of hops did this, you'd be in mailstorm hell. > via LocalDelivery, and my Mailet, which comes after this is filtering > everything else (ie the To, CC, and BCC which are not local) > In this case the RCPT-TO I am guessing (I have not checked yet) will > be empty. There are still recipients, but they are in the > MimeMessage. I suppose there may be occasions when the RCPT TO recipients are empty, but my gut reaction is that this would be an unusual situation for a message to be in, alive but heading nowhere. > The only way I can see around this, given the MimeMessageWrapper issue > is to use MimeMessageWrapper.addHeader and > MimeMessageWrapper.removeHeader to set the recipient list, which does > appear to write through to the underlying MimeMessage. The lists of addresses contained in the message headers of an email are, perverse but TRUE, _not_ used to route the message using SMTP, at best they are used by the sender to compose the initial set of RCPT TO recipients at worst they aren't used to route at all. They are useful to the recipient, however, for functions such as "REPLY TO ALL" and there are a number of cases where you maight want to modify them in order to control the behaviour of replies, like a mailing list does. What's more BCC recipients are not saved in a header in the message at all. If they were it would defeat the purpose of BCC which is to send a copy to someone without the other recipients knowing about it. In fact well behaved clients make use of the fact that the same message can be sent multiple times, to one recipient each time, to ensure that BCC is truly blind, and that no-one in posession of any copy can infer any of the BCC recipients without having access to the actual message destined for the BCC recipient themselves. > I am still worried however that the MimeMessageWrapper.getSize() and > MimeMessageWrapper.getMessageSize() functions return the size of the > original, rather than the amended MimeMessage. I am not sure whether > this is a problem yet... This is historic, and a known issue, it manifests itself as the wrong size being displayed in POP3 sessions, we haven't heard of any compelling reason to look at it again, and don't really want to as it would involve reading messages simply in order to measure their size. > Any thoughts on this matter appreciated. If you want to examine the manipulation of headers by James I suggest you look at AbstractRedirect and its children which manipulate recipients for both real destinations (RCPT TO) and in message headers: http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james /transport/mailets/AbstractRedirect.java http://james.apache.org/javadocs/index.html d. ************************************************************************ *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************ ** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
