[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-user
Subject:    Re: Mail stuck in outgoing
From:       Stefano Bagnara <apache () bago ! org>
Date:       2008-07-03 8:41:03
Message-ID: 9891282.140561.1215074485998.JavaMail.root () elysia ! void ! it
[Download RAW message or body]

Marc Chamberlin ha scritto:
> Stefano Bagnara wrote:
>> Marc Chamberlin ha scritto:
>>> Hi -  I am using James version 2.3.1 and am encountering a problem 
>>> with mail lists (and some email bounces apparently...) With mail 
>>> lists the server seems to be sending out the mail to a partial subset 
>>> of the members of the mail list and then I see the email sitting in 
>>> the Outgoing mail repository and the rest of the members of the list 
>>> are not receiving it. (I am also seeing some other emails sitting 
>>> there which look like attempts on James part to bounce spam/junk 
>>> mail, often due to address errors, which I don't really care about)
>>
>> I don't understand the problem. This seems the expected behaviour.
>> When a message is not deliverable for a temporary error it will wait 
>> in the outgoing spool for a next retry.
>>
>> You first say that it sends to a partial subset, but then you add that 
>> "the rest of the list are not receiving it". It should log an error 
>> when it decide to keep them in outgoing or to finally bounce them: is 
>> that error correct or not?
> Thanks Stephano for your reply. No, what I expect is for the mail list 
> server to send an email out to all members of the mail list in as timely 
> a fashion as possible. If one of the members in the list has suddenly 
> become unavailable, I don't expect the mail server to delay sending the 
> email to the rest of the members of the mail list, which is what it 
> seems to be doing.

Can you post your RemoteDelivery configuration?
Make sure you have true for the sendpartial config.
<!-- If false the message will not be sent to given server if any 
recipients fail -->
<sendpartial>true</sendpartial>

> I am getting reports back from users of a mail list 
> that some are getting the emails promptly after someone posts a message 
> to the group, and others are not getting the email or that it was 
> delivered days later, even though they do have a valid email address, 
> and nothing should have prevented prompt delivery of the email to them. 
> When I try to investigate, I discover the email is sitting in the 
> outgoing queue but I am not clear on why, and what succeeded and what 
> failed.

Are you using db or file repository?

We have to find if james is trying to deliver and temporarily fails or 
if your ougoing queue is stuck.

If you use db please check the "error_message" and "message_state" 
fields: message_state='outgoing' means the mail is in outgoing but never 
attempted to be delivered, 'error' means at least an attempt has been 
done. IN the second case "message_state" contains the number of attempts.
Please check if you have a lot of messages as "outgoing" or they all are 
"error", first.

In the mailet log (<jamesfolder>/apps/james/logs/mailets-XXXXX.log) you 
should see delivery attempts.
Just take a recipient and look in the log for errors. If james already 
attempted the delivery you should have logs about the issue that make 
him temporarily fail the send.

>>> I recently upgraded from an earlier version of James and the mailet 
>>> specifications in the config files have not changes and were working 
>>> fine. I see absolutely no indications of an error in the logfiles 
>>> other than socket reset exceptions occurring all the time in the 
>>> smtpserver log files. (This log file also shows a lot of attempts by 
>>> spammers to send stuff via my mail server, which is worrisome, and I 
>>> wish I had a way to understand what is happening there...)
>>
>> I bet this has nothing to do with james 2.3.1. It simply is happening 
>> that spamming botnets are very active in the last weeks.
> I agree that james 2.3.1 is innocent, but I wish I had some good 
> administrative tools to help me track emails through the server, i.e.  
> when an email was received, what mailets/matchers it when through, what 
> its disposition was and why (deleted, bounced, stored into a users inbox 
> repository, resent/forwarded etc.), and when accessed/picked up by a 
> client and whether the client asked to leave the message on the server 
> for a period of time, deleted it, or just left it there indefinitely. 
> This info does exist sorta, but all thrown together in the logfiles and 
> I need to be able to view things on a per client, per source, per 
> disposition basis etc also. (I would be quite surprised if others have 
> not asked for such tools also?)

This has already been asked in past. Unfortunately no developer seems to 
be interested in developing better logging or a tool for the analysis, 
so I don't have a solution for you.

> Also I would like a summary of attempts made to access the email server 
> (sorted for both successful and failed attempts, and with detailed 
> information about why failed attempts failed.) again for both sending 
> email via the server as well as picking up mail form the server. It is 
> extremely difficult to trace this through the log files especially when 
> one does not have a lot of understanding about the internals of the 
> James server.

the number of attempts is in the error_message field. Once you know the 
mail.key/name you can look in the mailet logs for errors (e.g: grep -A 
10 -B 10 <mail.key> mailet*.log).

> Without such views on the data processing done by the James server, I as 
> an administrator cannot KNOW if James is really handling emails 
> properly. Seeing stack walkbacks in the logfiles demonstrates that there 
> are exceptions not being properly handled, which does NOT give me a good 
> feeling that James is all that robust in standing up to attacks. All of 
> this makes me worry, hence my comment about it.

Why do you think they are not properly handled? The fact that they are 
logged does not necessarily mean they are not handled. Please post some 
of them (stack traces) so we can check.

Stefano

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

[prev in list] [next in list] [prev in thread] [next in thread]