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]
