[xmail] Re: 2-4 hour delay on relays....

2007-11-22 Thread Davide Libenzi
On Thu, 22 Nov 2007, David Lord wrote:

 I should have added that defaults for retries seem very conservative 
 and much safer for a production server than my values that ramp up 
 the period between reduced number of retries much more agressively.
 
 Davide, please correct me if I've calculated wrong but I work out 
 retries are at following times after initial attempt:

Actually, defaults are even too aggressive. Especially considering the 
fact that *many* servers now use greylisting.



- Davide


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-22 Thread David Lord
On 22 Nov 2007, at 11:51, Davide Libenzi wrote:

 On Thu, 22 Nov 2007, David Lord wrote:
 
  I should have added that defaults for retries seem very conservative 
  and much safer for a production server than my values that ramp up 
  the period between reduced number of retries much more agressively.
  
  Davide, please correct me if I've calculated wrong but I work out 
  retries are at following times after initial attempt:
 
 Actually, defaults are even too aggressive. Especially considering the 
 fact that *many* servers now use greylisting.

You're right, I'd missed that side effect of greylisting.

It does require a particular set of circumstances to hit a problem 
from it, not already being whitelisted together with connection 
failures over the period for first few retries. I suppose for a 
production server you're now stuck with needing a high value or zero 
for ratio and a high number of retries.

For me, I have three NotifyTryPattern points set and non appearance 
or otherwise seems a good enough way of indicating when an email has 
been sent.

David

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-21 Thread Dale Qualls
Same problem thing this morning.   Sent a message, waited 30 minutes and 
it's still sitting in the queue, no SLOG file, message was sitting in 
the spool just fine.  Restart XMail and the message flies on through.
Is there anything strange with my command line?  This is happening on 
both boxes.  Maybe the box is running low on memory?  They only have 
256MB of RAM and it looks like most of it is being used up (246MB).  I'm 
going to double the RAM and see if that makes a difference.  I bet XMail 
is maybe bogging down because it's getting killed by lack of RAM?

mx3:/ # top
top - 09:03:45 up 5 days, 32 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  52 total,   2 running,  50 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 98.8%id,  0.0%wa,  0.0%hi,  1.2%si,  
0.0%st
Mem:256724k total,   246544k used,10180k free,90496k buffers
Swap:   514040k total,   84k used,   513956k free,95008k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
14314 root  16   0  319m 3748 1584 S  0.3  1.5   0:21.38 XMail
1 root  16   0   720  284  244 S  0.0  0.1   0:00.58 init
2 root  34  19 000 S  0.0  0.0   0:00.04 ksoftirqd/0
3 root  10  -5 000 S  0.0  0.0   0:00.00 events/0
4 root  10  -5 000 S  0.0  0.0   0:00.00 khelper
5 root  10  -5 000 S  0.0  0.0   0:00.00 kthread
7 root  10  -5 000 S  0.0  0.0   0:01.79 kblockd/0
8 root  20  -5 000 S  0.0  0.0   0:00.00 kacpid
   98 root  15   0 000 S  0.0  0.0   2:30.25 pdflush
   99 root  15   0 000 S  0.0  0.0   0:02.91 pdflush
  101 root  20  -5 000 S  0.0  0.0   0:00.00 aio/0
  100 root  15   0 000 S  0.0  0.0   0:03.52 kswapd0
  307 root  11  -5 000 S  0.0  0.0   0:00.00 cqueue/0
  308 root  10  -5 000 S  0.0  0.0   0:00.00 kseriod
  348 root  11  -5 000 S  0.0  0.0   0:00.00 kpsmoused
  720 root  11  -5 000 S  0.0  0.0   0:00.00 scsi_eh_0
  809 root  10  -5 000 S  0.0  0.0   0:00.06 reiserfs/0


Thanks Davide.

Dale Qualls wrote:
 I had attempted with the file system before, there just wasn't a slog file.
 I followed your directions below but lo and behold the message 
 transferred immediately.

 MX2:/var/MailRoot/spool # grep -R [EMAIL PROTECTED] *
 MX2:/var/MailRoot/spool # cd ../logs
 MX2:/var/MailRoot/logs # grep -R [EMAIL PROTECTED] smail-20071120*
 pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 12:09:01
 pmnhg.net 1195590261005.2812046240.2312b.MX2S99D74E   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 15:13:36
 *pmnhg.net 1195597085232.2837445536.48.MX2   S9A27C9   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 16:18:05*
 MX2:/var/MailRoot/logs #

 So, I tried it again and it still transferred immediately:

 pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 12:09:01
 pmnhg.net 1195590261005.2812046240.2312b.MX2S99D74E   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 15:13:36
 pmnhg.net 1195597085232.2837445536.48.MX2   S9A27C9   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 16:18:05
 *pmnhg.net 1195597442419.2795482016.268.MX2  S9A29F4   
 [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
 10.5.10.3 2007-11-20 16:24:16*
 MX2:/var/MailRoot/logs #

 I'll let it run for a bit and try again.  Maybe when the spools get 
 loaded up it gets freaky?  I really doubt if that is the case as XMail 
 runs pretty damned clean and fast.  I sometimes have over 30,000 
 messages in the spool files though after a couple of days of running 
 (even with clearing the spool with the find command using -delete to 
 keep it clean)

 I'll test again in the morning and get back to you.

 Thanks Davide!


 Davide Libenzi wrote:
   
 On Tue, 20 Nov 2007, Dale Qualls wrote:

   
 
 Strange.  I flushed the queue, using Haralds manager, and it shot the 
 message right through.
 
   
 Ok, forget the tools. Let's go to the file system. Stop XMail and clean 
 the spool `find spool/ -type f | xargs rm -f` (if spossible - this will 
 nuke possible queued messages).
 Then send the message and look at the slog file. Just put a special text 
 mark in your message and:

 $ find spool/ -type f -exec grep -H TEXT_MARK {} \;

 You should have an associated slog file (same file name, inside the 
 corresponding slog directory).



 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: 

[xmail] Re: 2-4 hour delay on relays....

2007-11-21 Thread Davide Libenzi
On Wed, 21 Nov 2007, Dale Qualls wrote:

 Same problem thing this morning.   Sent a message, waited 30 minutes and 
 it's still sitting in the queue, no SLOG file, message was sitting in 
 the spool just fine.  Restart XMail and the message flies on through.
 Is there anything strange with my command line?  This is happening on 
 both boxes.  Maybe the box is running low on memory?  They only have 
 256MB of RAM and it looks like most of it is being used up (246MB).  I'm 
 going to double the RAM and see if that makes a difference.  I bet XMail 
 is maybe bogging down because it's getting killed by lack of RAM?
 
 mx3:/ # top
 top - 09:03:45 up 5 days, 32 min,  1 user,  load average: 0.00, 0.00, 0.00
 Tasks:  52 total,   2 running,  50 sleeping,   0 stopped,   0 zombie
 Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 98.8%id,  0.0%wa,  0.0%hi,  1.2%si,  
 0.0%st
 Mem:256724k total,   246544k used,10180k free,90496k buffers
 Swap:   514040k total,   84k used,   513956k free,95008k cached
 
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 14314 root  16   0  319m 3748 1584 S  0.3  1.5   0:21.38 XMail
 1 root  16   0   720  284  244 S  0.0  0.1   0:00.58 init
 2 root  34  19 000 S  0.0  0.0   0:00.04 ksoftirqd/0
 3 root  10  -5 000 S  0.0  0.0   0:00.00 events/0
 4 root  10  -5 000 S  0.0  0.0   0:00.00 khelper
 5 root  10  -5 000 S  0.0  0.0   0:00.00 kthread
 7 root  10  -5 000 S  0.0  0.0   0:01.79 kblockd/0
 8 root  20  -5 000 S  0.0  0.0   0:00.00 kacpid
98 root  15   0 000 S  0.0  0.0   2:30.25 pdflush
99 root  15   0 000 S  0.0  0.0   0:02.91 pdflush
   101 root  20  -5 000 S  0.0  0.0   0:00.00 aio/0
   100 root  15   0 000 S  0.0  0.0   0:03.52 kswapd0
   307 root  11  -5 000 S  0.0  0.0   0:00.00 cqueue/0
   308 root  10  -5 000 S  0.0  0.0   0:00.00 kseriod
   348 root  11  -5 000 S  0.0  0.0   0:00.00 kpsmoused
   720 root  11  -5 000 S  0.0  0.0   0:00.00 scsi_eh_0
   809 root  10  -5 000 S  0.0  0.0   0:00.06 reiserfs/0

Is this thing running NPTL as thread library? If yes, can you try to run 
an `ulimit -s 128` in the shell script running XMail?



- Davide


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-21 Thread David Lord
On 21 Nov 2007, at 9:27, Dale Qualls wrote:

 Same problem thing this morning.   Sent a message, waited 30 minutes and 
 it's still sitting in the queue, no SLOG file, message was sitting in 
 the spool just fine.  Restart XMail and the message flies on through.
 Is there anything strange with my command line?  This is happening on 


Yes

! Here is my command line (on both servers):
!
! XMAIL_CMD_LINE=-Pl -Sl -Ql -Qt 10 -Qr 50 -Yl -Fl -Cl -Ll -SX 100
!
! I've got the Qt set to 10 so after a failure it should retry a send 
! in
!
!10 minutes, correct?  All of the l are lower case Ls.

10 seconds?

I have -Qg -Qt 907 -Qi 1 -Qr 9

Default Qt 480 so I guess that's not minutes.

 both boxes.  Maybe the box is running low on memory?  They only have 
 256MB of RAM and it looks like most of it is being used up (246MB).  I'm 
 going to double the RAM and see if that makes a difference.  I bet XMail 
 is maybe bogging down because it's getting killed by lack of RAM?

Only a home server here, k6-400, NetBSD 3.1, total memory = 127 MB, 
avail memory = 119 MB. I used to send a batch of 12 emails from a 
remote account as test of spamassassin and fprot, 6 x connections 
each to 2 accounts. Occasionally all would slowly get through but 
mostly system crashed (I think there is a memory problem from NetBSD 
2.0 on and still not located/fixed with 4.0). Seemed most likely 
spamassassin perl script was using all memory but I set a check in 
both fprot and spamassassin to each limit number of scans to 2. That 
fixed the problem completely.

I'm sure possibly several years back I've had cases of seeing 
incoming email connections in firewall logs but nothing arriving in 
mailbox. Going through spool and deleting any that appeared to be 
spam would fix the problem. It's happened so infrequently that I 
never tried to work out exact cause.


David


 
 mx3:/ # top
 top - 09:03:45 up 5 days, 32 min,  1 user,  load average: 0.00, 0.00, 0.00
 Tasks:  52 total,   2 running,  50 sleeping,   0 stopped,   0 zombie
 Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 98.8%id,  0.0%wa,  0.0%hi,  1.2%si,  
 0.0%st
 Mem:256724k total,   246544k used,10180k free,90496k buffers
 Swap:   514040k total,   84k used,   513956k free,95008k cached
 
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 14314 root  16   0  319m 3748 1584 S  0.3  1.5   0:21.38 XMail
 1 root  16   0   720  284  244 S  0.0  0.1   0:00.58 init
 2 root  34  19 000 S  0.0  0.0   0:00.04 ksoftirqd/0
 3 root  10  -5 000 S  0.0  0.0   0:00.00 events/0
 4 root  10  -5 000 S  0.0  0.0   0:00.00 khelper
 5 root  10  -5 000 S  0.0  0.0   0:00.00 kthread
 7 root  10  -5 000 S  0.0  0.0   0:01.79 kblockd/0
 8 root  20  -5 000 S  0.0  0.0   0:00.00 kacpid
98 root  15   0 000 S  0.0  0.0   2:30.25 pdflush
99 root  15   0 000 S  0.0  0.0   0:02.91 pdflush
   101 root  20  -5 000 S  0.0  0.0   0:00.00 aio/0
   100 root  15   0 000 S  0.0  0.0   0:03.52 kswapd0
   307 root  11  -5 000 S  0.0  0.0   0:00.00 cqueue/0
   308 root  10  -5 000 S  0.0  0.0   0:00.00 kseriod
   348 root  11  -5 000 S  0.0  0.0   0:00.00 kpsmoused
   720 root  11  -5 000 S  0.0  0.0   0:00.00 scsi_eh_0
   809 root  10  -5 000 S  0.0  0.0   0:00.06 reiserfs/0
 
 
 Thanks Davide.
 
 Dale Qualls wrote:
  I had attempted with the file system before, there just wasn't a slog file.
  I followed your directions below but lo and behold the message 
  transferred immediately.
 
  MX2:/var/MailRoot/spool # grep -R [EMAIL PROTECTED] *
  MX2:/var/MailRoot/spool # cd ../logs
  MX2:/var/MailRoot/logs # grep -R [EMAIL PROTECTED] smail-20071120*
  pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
  [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
  10.5.10.3 2007-11-20 12:09:01
  pmnhg.net 1195590261005.2812046240.2312b.MX2S99D74E   
  [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
  10.5.10.3 2007-11-20 15:13:36
  *pmnhg.net 1195597085232.2837445536.48.MX2   S9A27C9   
  [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
  10.5.10.3 2007-11-20 16:18:05*
  MX2:/var/MailRoot/logs #
 
  So, I tried it again and it still transferred immediately:
 
  pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
  [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
  10.5.10.3 2007-11-20 12:09:01
  pmnhg.net 1195590261005.2812046240.2312b.MX2S99D74E   
  [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
  10.5.10.3 2007-11-20 15:13:36
  pmnhg.net 1195597085232.2837445536.48.MX2   S9A27C9   
  [EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
  10.5.10.3 2007-11-20 16:18:05
  *pmnhg.net 1195597442419.2795482016.268.MX2

[xmail] Re: 2-4 hour delay on relays....

2007-11-21 Thread Davide Libenzi
On Wed, 21 Nov 2007, David Lord wrote:

 Only a home server here, k6-400, NetBSD 3.1, total memory = 127 MB, 
 avail memory = 119 MB. I used to send a batch of 12 emails from a 
 remote account as test of spamassassin and fprot, 6 x connections 
 each to 2 accounts. Occasionally all would slowly get through but 
 mostly system crashed (I think there is a memory problem from NetBSD 
 2.0 on and still not located/fixed with 4.0). Seemed most likely 
 spamassassin perl script was using all memory but I set a check in 
 both fprot and spamassassin to each limit number of scans to 2. That 
 fixed the problem completely.
 
 I'm sure possibly several years back I've had cases of seeing 
 incoming email connections in firewall logs but nothing arriving in 
 mailbox. Going through spool and deleting any that appeared to be 
 spam would fix the problem. It's happened so infrequently that I 
 never tried to work out exact cause.

This is very likely due to filters timing out.



- Davide


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-21 Thread David Lord
On 21 Nov 2007, at 23:27, David Lord wrote:

 On 21 Nov 2007, at 9:27, Dale Qualls wrote:
 
  Same problem thing this morning.   Sent a message, waited 30 minutes and 
  it's still sitting in the queue, no SLOG file, message was sitting in 
  the spool just fine.  Restart XMail and the message flies on through.
  Is there anything strange with my command line?  This is happening on 
 
 
 Yes
 
 ! Here is my command line (on both servers):
 !
 ! XMAIL_CMD_LINE=-Pl -Sl -Ql -Qt 10 -Qr 50 -Yl -Fl -Cl -Ll -SX 100
 !
 ! I've got the Qt set to 10 so after a failure it should retry a send 
 ! in
 !
 !10 minutes, correct?  All of the l are lower case Ls.
 
 10 seconds?
 
 I have -Qg -Qt 907 -Qi 1 -Qr 9
 
 Default Qt 480 so I guess that's not minutes.

I should have added that defaults for retries seem very conservative 
and much safer for a production server than my values that ramp up 
the period between reduced number of retries much more agressively.

Davide, please correct me if I've calculated wrong but I work out 
retries are at following times after initial attempt:

Qt,Qi,Qr  480,16,32  10,16,51   907,1,9

Retry hhh:mm:ss hhh:mm:ss hhh:mm:ss
 1  0: 8: 0   0: 0:10   0:15: 7 
 2  0:16:30   0: 0:20   0:45:21 
 3  0:25:31   0: 0:31   1:45:49 
 4  0:35: 7   0: 0:43   3:46:45 
 5  0:45:19   0: 0:56   7:48:37 
 6  0:56: 9   0: 1:10  15:52:21 
 7  1: 7:39   0: 1:24  31:59:49 
 8  1:19:53   0: 1:39  64:14:45 
 9  1:32:53   0: 1:56 128:44:37 
..
29 10:14:35   0:12:48
30 11: 1: 0   0:13:46
31 11:50:18   0:14:47
32 12:42:42   0:15:53
..
470:43:24
480:46:17
490:49:20
500:52:35



David

-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-20 Thread Davide Libenzi
On Tue, 20 Nov 2007, Dale Qualls wrote:

 Hello all, I've got a bit of a head scratcher here.
 
 I have a couple of XMail boxes setup to do relaying (no filtering of any 
 kind) as backup MX servers and I've never really paid much attention but 
 it appears that they relay received messages about 2-4 hours after it is 
 received.  I had someone complain about it recently so I did a bit of 
 testing (and a couple of restarts, even though on a *nix box it 
 shouldn't need it).   Dates and times are correct on the servers.
 
 I did a telnet session to localhost from this server (MX2) and sent a 
 message to my office account (changed to myofficeacct in the text below) 
 from this account and it really did take 4 hours to get through.  Here's 
 the log info:
 
 MX2:/var/MailRoot/logs # grep [EMAIL PROTECTED] smtp-20071120
 pmnhg.net pmnhg.net 127.0.0.1 2007-11-20 08:05:07   
 radtechnologies.net  myofficeacct.com
 [EMAIL PROTECTED]   [EMAIL PROTECTED] com
 S99747F   RCPT=OK 0 
 pmnhg.net pmnhg.net 127.0.0.1 2007-11-20 08:05:22   
 radtechnologies.net  myofficeacct.com
 [EMAIL PROTECTED]   [EMAIL PROTECTED] com
 S99747F   RECV=OK 15
 
 MX2:/var/MailRoot/logs # grep [EMAIL PROTECTED] smail-20071120
 pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
 [EMAIL PROTECTED] technologies.net   [EMAIL PROTECTED]
 RLYS  10.5.10.3 2007-11 -20 12:09:01
 MX2:/var/MailRoot/logs # date
 Tue Nov 20 12:14:10 CST 2007
 
 I then did a telnet session to MX3 from MX2 and sent a message to my 
 office account (changed to myofficeacct in the text below) from this 
 account and it took 2 hours to get through.  Here's the log info:
 
 
 mx3:/var/MailRoot/logs # grep [EMAIL PROTECTED] *20071120*
 smail-20071120:pmnhg.net  1195567409683.2820668320.a46e.mx3 
 S4F17C3   [EMAIL PROTECTED]   
 [EMAIL PROTECTED]RLYS  10.5.10.32007-11-20 10:02:57
 
 smtp-20071120:pmnhg.net   pmnhg.net 10.5.10.114   
 2007-11-20 08:03:24   radtechnologies.net   
 myofficeacct.com[EMAIL PROTECTED]  
 [EMAIL PROTECTED] S4F17C3   RCPT=OK 
 0 
 smtp-20071120:pmnhg.net   pmnhg.net 10.5.10.114   
 2007-11-20 08:03:29   radtechnologies.net   
 myofficeacct.com[EMAIL PROTECTED]  
 [EMAIL PROTECTED] S4F17C3   RECV=OK 
 14
 mx3:/var/MailRoot/logs # date
 Tue Nov 20 12:33:54 CST 2007
 mx3:/var/MailRoot/logs #
 
 
 Here is my command line (on both servers):
 
 XMAIL_CMD_LINE=-Pl -Sl -Ql -Qt 10 -Qr 50 -Yl -Fl -Cl -Ll -SX 100
 
 I've got the Qt set to 10 so after a failure it should retry a send in 
 10 minutes, correct?  All of the l are lower case Ls.
 
 Kinda strange.  I have to assume it's always done this.
 
 Any nuggets of wisdom on what I should look at?  Both servers are XMail 
 1.24 on SLES10.1

Try again, but this time after 10-20 minutes, go inside the spool and 
search for your message. Then post the associated slog file.



- Davide


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-20 Thread Dale Qualls
I sent the test message at 2:24 p.m. CST and now at 3:19 p.m. CST it 
still sits in the spool but there is no slog file.  I didn't find a 
corresponding one in the slog directory (although there are many others) 
and using Haralds xmail queue manager it simply says NO_SLOG_FILE.
Shall I bounce the box to see if things begin moving?



Davide Libenzi wrote:
 On Tue, 20 Nov 2007, Dale Qualls wrote:

   
 Hello all, I've got a bit of a head scratcher here.

 I have a couple of XMail boxes setup to do relaying (no filtering of any 
 kind) as backup MX servers and I've never really paid much attention but 
 it appears that they relay received messages about 2-4 hours after it is 
 received.  I had someone complain about it recently so I did a bit of 
 testing (and a couple of restarts, even though on a *nix box it 
 shouldn't need it).   Dates and times are correct on the servers.

 I did a telnet session to localhost from this server (MX2) and sent a 
 message to my office account (changed to myofficeacct in the text below) 
 from this account and it really did take 4 hours to get through.  Here's 
 the log info:

 MX2:/var/MailRoot/logs # grep [EMAIL PROTECTED] smtp-20071120
 pmnhg.net pmnhg.net 127.0.0.1 2007-11-20 08:05:07   
 radtechnologies.net  myofficeacct.com
 [EMAIL PROTECTED]   [EMAIL PROTECTED] com
 S99747F   RCPT=OK 0 
 pmnhg.net pmnhg.net 127.0.0.1 2007-11-20 08:05:22   
 radtechnologies.net  myofficeacct.com
 [EMAIL PROTECTED]   [EMAIL PROTECTED] com
 S99747F   RECV=OK 15

 MX2:/var/MailRoot/logs # grep [EMAIL PROTECTED] smail-20071120
 pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
 [EMAIL PROTECTED] technologies.net   [EMAIL PROTECTED]
 RLYS  10.5.10.3 2007-11 -20 12:09:01
 MX2:/var/MailRoot/logs # date
 Tue Nov 20 12:14:10 CST 2007

 I then did a telnet session to MX3 from MX2 and sent a message to my 
 office account (changed to myofficeacct in the text below) from this 
 account and it took 2 hours to get through.  Here's the log info:


 mx3:/var/MailRoot/logs # grep [EMAIL PROTECTED] *20071120*
 smail-20071120:pmnhg.net  1195567409683.2820668320.a46e.mx3 
 S4F17C3   [EMAIL PROTECTED]   
 [EMAIL PROTECTED]RLYS  10.5.10.32007-11-20 10:02:57

 smtp-20071120:pmnhg.net   pmnhg.net 10.5.10.114   
 2007-11-20 08:03:24   radtechnologies.net   
 myofficeacct.com[EMAIL PROTECTED]  
 [EMAIL PROTECTED] S4F17C3   RCPT=OK 
 0 
 smtp-20071120:pmnhg.net   pmnhg.net 10.5.10.114   
 2007-11-20 08:03:29   radtechnologies.net   
 myofficeacct.com[EMAIL PROTECTED]  
 [EMAIL PROTECTED] S4F17C3   RECV=OK 
 14
 mx3:/var/MailRoot/logs # date
 Tue Nov 20 12:33:54 CST 2007
 mx3:/var/MailRoot/logs #


 Here is my command line (on both servers):

 XMAIL_CMD_LINE=-Pl -Sl -Ql -Qt 10 -Qr 50 -Yl -Fl -Cl -Ll -SX 100

 I've got the Qt set to 10 so after a failure it should retry a send in 
 10 minutes, correct?  All of the l are lower case Ls.

 Kinda strange.  I have to assume it's always done this.

 Any nuggets of wisdom on what I should look at?  Both servers are XMail 
 1.24 on SLES10.1
 

 Try again, but this time after 10-20 minutes, go inside the spool and 
 search for your message. Then post the associated slog file.



 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-20 Thread Dale Qualls
Strange.  I flushed the queue, using Haralds manager, and it shot the 
message right through.
Davide Libenzi wrote:
 On Tue, 20 Nov 2007, Dale Qualls wrote:

   
 Hello all, I've got a bit of a head scratcher here.

 I have a couple of XMail boxes setup to do relaying (no filtering of any 
 kind) as backup MX servers and I've never really paid much attention but 
 it appears that they relay received messages about 2-4 hours after it is 
 received.  I had someone complain about it recently so I did a bit of 
 testing (and a couple of restarts, even though on a *nix box it 
 shouldn't need it).   Dates and times are correct on the servers.

 I did a telnet session to localhost from this server (MX2) and sent a 
 message to my office account (changed to myofficeacct in the text below) 
 from this account and it really did take 4 hours to get through.  Here's 
 the log info:

 MX2:/var/MailRoot/logs # grep [EMAIL PROTECTED] smtp-20071120
 pmnhg.net pmnhg.net 127.0.0.1 2007-11-20 08:05:07   
 radtechnologies.net  myofficeacct.com
 [EMAIL PROTECTED]   [EMAIL PROTECTED] com
 S99747F   RCPT=OK 0 
 pmnhg.net pmnhg.net 127.0.0.1 2007-11-20 08:05:22   
 radtechnologies.net  myofficeacct.com
 [EMAIL PROTECTED]   [EMAIL PROTECTED] com
 S99747F   RECV=OK 15

 MX2:/var/MailRoot/logs # grep [EMAIL PROTECTED] smail-20071120
 pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
 [EMAIL PROTECTED] technologies.net   [EMAIL PROTECTED]
 RLYS  10.5.10.3 2007-11 -20 12:09:01
 MX2:/var/MailRoot/logs # date
 Tue Nov 20 12:14:10 CST 2007

 I then did a telnet session to MX3 from MX2 and sent a message to my 
 office account (changed to myofficeacct in the text below) from this 
 account and it took 2 hours to get through.  Here's the log info:


 mx3:/var/MailRoot/logs # grep [EMAIL PROTECTED] *20071120*
 smail-20071120:pmnhg.net  1195567409683.2820668320.a46e.mx3 
 S4F17C3   [EMAIL PROTECTED]   
 [EMAIL PROTECTED]RLYS  10.5.10.32007-11-20 10:02:57

 smtp-20071120:pmnhg.net   pmnhg.net 10.5.10.114   
 2007-11-20 08:03:24   radtechnologies.net   
 myofficeacct.com[EMAIL PROTECTED]  
 [EMAIL PROTECTED] S4F17C3   RCPT=OK 
 0 
 smtp-20071120:pmnhg.net   pmnhg.net 10.5.10.114   
 2007-11-20 08:03:29   radtechnologies.net   
 myofficeacct.com[EMAIL PROTECTED]  
 [EMAIL PROTECTED] S4F17C3   RECV=OK 
 14
 mx3:/var/MailRoot/logs # date
 Tue Nov 20 12:33:54 CST 2007
 mx3:/var/MailRoot/logs #


 Here is my command line (on both servers):

 XMAIL_CMD_LINE=-Pl -Sl -Ql -Qt 10 -Qr 50 -Yl -Fl -Cl -Ll -SX 100

 I've got the Qt set to 10 so after a failure it should retry a send in 
 10 minutes, correct?  All of the l are lower case Ls.

 Kinda strange.  I have to assume it's always done this.

 Any nuggets of wisdom on what I should look at?  Both servers are XMail 
 1.24 on SLES10.1
 

 Try again, but this time after 10-20 minutes, go inside the spool and 
 search for your message. Then post the associated slog file.



 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-20 Thread Davide Libenzi
On Tue, 20 Nov 2007, Dale Qualls wrote:

 Strange.  I flushed the queue, using Haralds manager, and it shot the 
 message right through.

Ok, forget the tools. Let's go to the file system. Stop XMail and clean 
the spool `find spool/ -type f | xargs rm -f` (if spossible - this will 
nuke possible queued messages).
Then send the message and look at the slog file. Just put a special text 
mark in your message and:

$ find spool/ -type f -exec grep -H TEXT_MARK {} \;

You should have an associated slog file (same file name, inside the 
corresponding slog directory).



- Davide


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]



[xmail] Re: 2-4 hour delay on relays....

2007-11-20 Thread Dale Qualls
I had attempted with the file system before, there just wasn't a slog file.
I followed your directions below but lo and behold the message 
transferred immediately.

MX2:/var/MailRoot/spool # grep -R [EMAIL PROTECTED] *
MX2:/var/MailRoot/spool # cd ../logs
MX2:/var/MailRoot/logs # grep -R [EMAIL PROTECTED] smail-20071120*
pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 12:09:01
pmnhg.net 1195590261005.2812046240.2312b.MX2S99D74E   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 15:13:36
*pmnhg.net 1195597085232.2837445536.48.MX2   S9A27C9   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 16:18:05*
MX2:/var/MailRoot/logs #

So, I tried it again and it still transferred immediately:

pmnhg.net 1195567522962.2820438944.1ca30.MX2S99747F   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 12:09:01
pmnhg.net 1195590261005.2812046240.2312b.MX2S99D74E   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 15:13:36
pmnhg.net 1195597085232.2837445536.48.MX2   S9A27C9   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 16:18:05
*pmnhg.net 1195597442419.2795482016.268.MX2  S9A29F4   
[EMAIL PROTECTED]   [EMAIL PROTECTED]RLYS  
10.5.10.3 2007-11-20 16:24:16*
MX2:/var/MailRoot/logs #

I'll let it run for a bit and try again.  Maybe when the spools get 
loaded up it gets freaky?  I really doubt if that is the case as XMail 
runs pretty damned clean and fast.  I sometimes have over 30,000 
messages in the spool files though after a couple of days of running 
(even with clearing the spool with the find command using -delete to 
keep it clean)

I'll test again in the morning and get back to you.

Thanks Davide!


Davide Libenzi wrote:
 On Tue, 20 Nov 2007, Dale Qualls wrote:

   
 Strange.  I flushed the queue, using Haralds manager, and it shot the 
 message right through.
 

 Ok, forget the tools. Let's go to the file system. Stop XMail and clean 
 the spool `find spool/ -type f | xargs rm -f` (if spossible - this will 
 nuke possible queued messages).
 Then send the message and look at the slog file. Just put a special text 
 mark in your message and:

 $ find spool/ -type f -exec grep -H TEXT_MARK {} \;

 You should have an associated slog file (same file name, inside the 
 corresponding slog directory).



 - Davide


 -
 To unsubscribe from this list: send the line unsubscribe xmail in
 the body of a message to [EMAIL PROTECTED]
 For general help: send the line help in the body of a message to
 [EMAIL PROTECTED]


   


-
To unsubscribe from this list: send the line unsubscribe xmail in
the body of a message to [EMAIL PROTECTED]
For general help: send the line help in the body of a message to
[EMAIL PROTECTED]