Re: ToSenderFolder Mailet Failure (James 3)

[Jerry Malcolm]

Update

I updated the ToSenderFolder mailet and got it to work properly with my 
account that uses RecipientRewrite.


I cloned some lines from the LocalDelivery mailet that sets up the rrt 
variable via inject.  In ToSenderFolder.doService(), I first call 
rrt.getMappings() using the sender email address.  If result != 
null, I pull the username string from the result.  If result=null, I 
fall back to the existing code that uses the sender email as the username.


Minimal testing so far.  But it appears to be working correctly now.

As I stated in my previous email, I think this is a bug in the mailet 
and not a feature request.  The mailet should handle by default the 
situation where the sender email address is NOT the username, and not 
require my custom hack to make it work.


Thanks.

Jerry


On 7/4/2014 8:30 PM, Jerry Malcolm wrote:
I tried activating the ToSenderFolder mailet and could not get it to 
work.  I added some debug code and looked through the source, and I 
see where the problem is.


The mailet assumes that the username (user login name / repository 
name) is the sender's email address. (see code snippit at the bottom 
of this post). Where this 'could' be the case, and could be argued 
that it's that way in many situations, it's not required. My login id 
for my mail account is m...@mycompany.net. I have several employees 
that share this one account.  However, they send mail as 
j...@mycompany.net, b...@mycompany.net, and su...@mycompany.net.  I use 
the virtual recipient rewrite function to map all of these ids to the 
m...@mycompany.net repository.


The problem in the mailet is that it is trying to put sent mail in 
j...@mycompany.net/Sent, etc. which is not a valid repository.


In order to fix this, I need to figure out the real username that was 
used to log in to SMTP.   I suspect you're going to tell me that 
there's not a way in the world to get addressability to the real 
username inside a mailet, right...?  I guess the next option would be 
to use the recipient rewrite table in the db to map the sender to the 
repository.  I'll look around for a recipient rewrite mapping class 
that I can use.  Or I guess I could just brute-force it directly with 
a SQL query to the table in the db. Either way, I should be able to 
determine the real repository name so the mailet can know where to put 
the Sent message.


I believe there is a philosophical design problem currently in the 
mailet to assume the sender email address is the repository name. But 
since I need to go ahead and fix this, I'd like to know what the James 
team would suggest to be the 'right way' to implement the fix.


Suggestions?

Thx.

Jerry
-- code snippit--
String username;
try {
if (usersRepository.supportVirtualHosting()) {
username = sender.toString();
}
else {
username = sender.getLocalPart();
}
} catch (UsersRepositoryException e) {
throw new MessagingException(e.getMessage());
}




-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4592 / Virus Database: 3986/7800 - Release Date: 07/04/14



-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org

Re: Preserving MAIL_IS_SEEN state?

[Jerry Malcolm]

Hi Eric,

The RFC pretty doesn't specifically refer to the SEEN flag in reference 
to READ_ONLY state.  But it does say that:


  If the client is not permitted to modify the mailbox but is
  permitted read access, the mailbox is selected as read-only,

It doesn't specifically define READ-ONLY and what is and is not 
included.  But unless there are
some extenuating circumstances that I didn't come across, I think it's 
safe to assume that when
the mailbox is open in READ-ONLY state, nothing should be changed, 
including the SEEN flag.


But I'll admit I'm not intimately familiar with the RFC.  I was 
initially just hoping one of the
developers of JAMES 3 would be able to confirm that READ-ONLY should 
include the SEEN flag state.


If the developer says that there is actually a reason why SEEN should 
not fall under READ-ONLY state,
I'll just figure a way to work around it. But assuming READ-ONLY can be 
interpreted using the classic
definition, and the SEEN state should NOT be modified when READ-ONLY, 
then I believe there is a bug.

I can provide a test case.

Is it better just to provide some java source for the test case that can 
be compiled into an
executable jar?  Or do you prefer the compiled/built jar?  If that's the 
case, how do I deliver

it to you?

Alternatively, I have the entire J3 source. But there are a ton of 
packages and java files and I'm not
that familiar with the code.  If you can tell me the java class where 
the SEEN flag is set/cleared,
it'd probably be faster for me to just look at the code and see if I can 
see what is happening.


The initial question is 'should' SEEN come under READ-ONLY and not 
be changed in READ-ONLY state?


If so, we can proceed with figuring out why it does not appear to be 
behaving correctly.


Thanks.

Jerry

On 6/20/2014 12:27 AM, Eric Charles wrote:

Hi Jerry,

Thank for joining and sorry for the late answer.

The best way to tackle this is to point the rfc section where you think
james does not behave as expected. You could also upload a simple test
case that shows this.

Eric


On 05/18/2014 10:06 PM, Jerry Malcolm wrote:

I am desperately trying to figure out a way to access a message without
having the MAIL_IS_SEEN flag set.   I have some background server apps
that need to scan folders and do various automated maintenance tasks.  I
do not want unread mail to be marked as seen just because the utility
happened to pass over it.  Yet I can't seem to stop it from happening.
I saw some posts on IMAP forums that said this was the way IMAP worked.
Really?  There is absolute NO WAY to scan a folder and look at messages
in a background utility and maintain the MAIL_IS_SEEN state if it hasn't
really been seen by the user?

I have a test case that verifies what is happening:

-- direct SQL query to JAMES_Mail record in db to check MAIL_IS_SEEN
(initially = 0)
-- folder.open(Folder.READ_ONLY);
-- message = ((UIDFolder)folder).getMessageByUID( uid );
-- direct SQL query to JAMES_Mail record in db to check MAIL_IS_SEEN (
changed to 1)

I figured that if I opened the folder in READ_ONLY mode, then, by
definition of the term READ_ONLY I would not have 'change' authority,
and therefore the MAIL_IS_SEEN flag would not be affected.  No
difference.  Even opening a folder in READ_ONLY mode causes all of the
mail to be set to 'SEEN'.

Am I missing something really obvious here?  I can't believe there is no
benign way to scan a folder without JAMES automatically deciding that
all mail has now been 'seen'.

Am I totally misunderstanding READ_ONLY mode of folders?  Is this a bug
in JAMES?  Is there a totally different way to access a message via a
Java program WITHOUT having JAMES auto-set it to 'seen'?  Or am I
basically out of luck?

Thanks.

Jerry


-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4592 / Virus Database: 3986/7797 - Release Date: 07/04/14



-
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org