smtproutes and mail still in queue
Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? Thank you in advance for any help. -- Subba Rao [EMAIL PROTECTED] http://members.home.net/subba9/ GPG public key ID 27FC9217 Key fingerprint = 2B4C 498E 1860 5A2B 6570 5852 7527 882A 27FC 9217
Re: smtproutes and mail still in queue
On Fri, Jul 06, 2001 at 06:36:19AM +, Subba Rao wrote: Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? What do the logs say? Has qmail-send tried any deliveries to gbnet.net since you altered smtproutes?
Re: smtproutes and mail still in queue
On 0, Alex Pennace [EMAIL PROTECTED] wrote: On Fri, Jul 06, 2001 at 06:36:19AM +, Subba Rao wrote: Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? What do the logs say? Has qmail-send tried any deliveries to gbnet.net since you altered smtproutes? --- Jun 29 22:15:54 myhost qmail: 993852954.669066 starting delivery 65: msg 197156 to remote [EMAIL PROTECTED] Jun 29 22:15:54 myhost qmail: 993852954.670044 status: local 0/10 remote 1/20 Jun 29 22:15:55 myhost qmail: 993852955.514653 delivery 65: deferral: Connected_to_194.70.126.10_but_connection_died._(#4.4.2)/ Jun 29 22:15:55 myhost qmail: 993852955.515821 status: local 0/10 remote 0/20 Jun 29 22:22:35 myhost qmail: 993853355.538097 starting delivery 66: msg 197156 to remote [EMAIL PROTECTED] Jun 29 22:22:35 myhost qmail: 993853355.538447 status: local 0/10 remote 1/20 Jun 29 22:22:36 myhost qmail: 993853356.268755 delivery 66: deferral: Connected_to_194.70.126.10_but_connection_died._(#4.4.2)/ Jun 29 22:22:36 myhost qmail: 993853356.269908 status: local 0/10 remote 0/20 --- The following is from this morning. --- Jul 6 06:22:35 myhost qmail: 994400555.804312 starting delivery 59: msg 197156 to remote [EMAIL PROTECTED] Jul 6 06:22:35 myhost qmail: 994400555.804480 status: local 0/10 remote 1/20 Jul 6 06:22:45 myhost qmail: 994400565.356285 delivery 59: deferral: Connected_to_194.70.126.10_but_connection_died._(#4.4.2)/ Jul 6 06:22:45 myhost qmail: 994400565.356445 status: local 0/10 remote 0/20 --- The mail is still in the queue. Here is the output of mailq, 29 Jun 2001 22:15:54 GMT #197156 621 [EMAIL PROTECTED] remote [EMAIL PROTECTED] The smtproutes has the following entry: gbnet.net:mail.home.com I have tried the following too: .gbnet.net:mail.home.com -- Subba Rao [EMAIL PROTECTED] http://members.home.net/subba9/ GPG public key ID 27FC9217 Key fingerprint = 2B4C 498E 1860 5A2B 6570 5852 7527 882A 27FC 9217
RE: smtproutes and mail still in queue
My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? Thank you in advance for any help. -- Look at the recipients of mutt list messages. You subscribe to gbnet.net but the message recipients are @mutt.org You can post to @mutt.org too hope this help ~edu
Re: smtproutes and mail still in queue
On Fri, Jul 06, 2001 at 06:36:41AM +, Subba Rao wrote: Hi, My mail client is Mutt. Few days ago I have subscribed to their mailing list. Their list server is at gbnet.net. The list server attempts to authenticate my server by calling to identd. I have opened up ipchains to access identd for the gbnet.net domain and the mail is still the mail queue. Since my initial subscription (sometime ago) to Mutt list, I have added the gbnet.net in the /var/qmail/control/smtproutes file. The relaying server is my ISP's mail server. In this case, this mail should have left my system long time ago but it still remains in the mail queue. Why is it trying to authenticate my system via identd when the smtproutes has been defined for this domain? qmail does not ignore control files. Verify that /var/qmail/control/smtproutes contains the correct information (and is named correctly), restart qmail, send qmail-send an ALRM signal to retry all queued mail, and watch the mail fly off to your ISP. Thank you in advance for any help. NP. :) -- Greg White
