...making Linux just a little more fun!
John Karns [johnkarns at gmail.com]
Thu, 7 Sep 2006 08:56:21 -0500
Hi All,
I'm getting lots of bounce notices regarding incoming mail from gmail. I'm baffled. Would this be generated by my host?
1) I'm popping with fetchmail.
2) Due to postfix (yuck) sending mail to the bit-bucket, I've tried bypassing it and specifying procmail as the mda in .fetchmailrc.
I don't understand why it cites failure to establish an smtp connection with jkarns at localhost:
TEMP_FAILURE: Could not initiate SMTP conversation with any hosts: [localhost (1): Connection refused]
It would make a little more sense to me to see msgs like this being generated by postfix on my host, but don't see what POPping from gmail should be related in any way to an smtp connection.
Any suggestions / help much appreciated.
Here's an example:
========================================================
This is an automatically generated Delivery Status Notification
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipient has been delayed:
jkarns at localhost
Message will be retried for 1 more day(s)
########################################################
Technical details of temporary failure:
TEMP_FAILURE: Could not initiate SMTP conversation with any hosts:
[localhost (1): Connection refused]
########################################################
----- Message header follows -----
Received: by 10.35.121.9 with SMTP id y9mr11471496pym;
Mon, 04 Sep 2006 20:04:06 -0700 (PDT)
Return-Path: <johnkarns at gmail.com>
Received: from jkInsp8100.jkarns.net ( [201.245.240.39])
by mx.gmail.com with ESMTP id j7sm4766097nzd.2006.09.04.20.04.05;
MoX-Gmail-Received: 09b9b341ceca6eceabfefde469e57f09c7388744
Delivered-To: johnkarns at gmail.com
Received: by 10.65.152.2 with SMTP id e2cs138724qbo;
Sat, 2 Sep 2006 21:48:00 -0700 (PDT)
Received: by 10.35.20.14 with SMTP id x14mr6879266pyi;
Sat, 02 Sep 2006 21:48:00 -0700 (PDT)
Received: from linuxmafia.com (linuxmafia.com [198.144.195.186])
by mx.gmail.com with ESMTP id q71si3589119pyg.2006.09.02.21.47.56;
Sat, 02 Sep 2006 21:48:00 -0700 (PDT)
Received-SPF: neutral (gmail.com: 198.144.195.186 is neither permitted nor denie
Received: from localhost ([127.0.0.1]:55105 helo=linuxmafia.com)
by linuxmafia.com with esmtp (Exim 4.61 #1 (EximConfig 2.0))
id 1GJjsg-00062B-E1 ; Sat, 02 Sep 2006 21:46:53 -0700
Received: from wx-out-0506.google.com ([66.249.82.236]:46345)
by linuxmafia.com with esmtp (Exim 4.61 #1 (EximConfig 2.0))
id 1GJjrq-000620-SO
for <tag at lists.linuxgazette.net>; Sat, 02 Sep 2006 21:46:08 -0700
Received: by wx-out-0506.google.com with SMTP id s14so1489812wxc
for <tag at lists.linuxgazette.net>; Sat, 02 Sep 2006 21:45:54 -0700 (PDT)
Received: by 10.90.49.19 with SMTP id w19mr977497agw;
Sat, 02 Sep 2006 21:45:54 -0700 (PDT)
Received: by 10.90.97.15 with HTTP; Sat, 2 Sep 2006 21:45:54 -0700 (PDT)
Message-ID: <300ccfa50609022145p131f9f01xd674f7a952763d5 at mail.gmail.com>
Date: Sun, 3 Sep 2006 00:45:54 -0400
To: "The Answer Gang" <tag at lists.linuxgazette.net>
In-Reply-To: <20060903034516.GA8951 at linuxgazette.net>
MIME-Version: 1.0
References: <OFC9AB447D.DCC3207C-ON852571DE.00064D6A-852571DE.00066419 at us.ibm.co
<20060903013209.GA3897 at linuxgazette.net>
<300ccfa50609021910n2b4f74a5tfae51b152eb3d1f3 at mail.gmail.com>
<20060903034516.GA8951 at linuxgazette.net>
X-Google-Sender-Auth: 419663e775fc28bb
Received-SPF: pass (linuxmafia.com: domain of faberfedor at gmail.com designates
66.249.82.236 as permitted sender)
X-EximConfig: v2.0 on linuxmafia.com (http://www.jcdigita.com/eximconfig)
X-BeenThere: tag at lists.linuxgazette.net
X-Mailman-Version: 2.1.8rc1
Precedence: list
Reply-To: The Answer Gang <tag at lists.linuxgazette.net>
List-Id: The Answer Gang <tag.lists.linuxgazette.net>
List-Unsubscribe: <http://lists.linuxgazette.net/mailman/listinfo/tag>,
<mailto:tag-request at lists.linuxgazette.net?subject=unsubscribe>
List-Archive: <http://lists.linuxgazette.net/mailman/private/tag>
List-Post: <mailto:tag at lists.linuxgazette.net>
List-Help: <mailto:tag-request at lists.linuxgazette.net?subject=help>
List-Subscribe: <http://lists.linuxgazette.net/mailman/listinfo/tag>,
<mailto:tag-request at lists.linuxgazette.net?subject=subscribe>
Mime-version: 1.0
Errors-To: tag-bounces at lists.linuxgazette.net
X-EximConfig: v2.0 on linuxmafia.com (http://www.jcdigita.com/eximconfig)
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: tag-bounces at lists.linuxgazette.net
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on linuxmafia.com
X-Spam-Level:
X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00,HTML_50_60,
HTML_MESSAGE,SPF_HELO_PASS autolearn=unavailable version=3.1.1
Subject: Re: [TAG] Talkback:129/okopnik1.html
Content-Type: multipart/mixed; boundary="===============2109663561=="
X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200)
From: Faber Fedor <johnkarns@gmail.com>n, 04 Sep 2006 20:04:06 -0700 (PDT)
To: TAG <tag@lists.linuxgazette.net>
Received: from localhost (localhost.localdomain [127.0.0.1])
by jkInsp8100.jkarns.net (Postfix) with ESMTP id 0EEA5460A9
for <jkarns at localhost>; Mon, 4 Sep 2006 22:03:50 -0500 (COT)
Received: from gmail-pop.l.google.com [64.233.163.111]
by localhost with POP3 (fetchmail-6.2.5)
for jkarns at localhost (single-drop); Mon, 04 Sep 2006 22:03:50 -0500 (COT)
========================================================
John Karns [johnkarns at gmail.com]
Thu, 7 Sep 2006 09:38:39 -0500
... just made a correction to .fetchmailrc's user var "smtphost". Was set to localhost, and it should agree with the myhostname var in /etc/postfix/main.cf; then redirected fetchmail to postfix.
Maybe that will address the problem.
Neil Youngman [ny at youngman.org.uk]
Thu, 7 Sep 2006 15:58:51 +0100
On or around Thursday 07 September 2006 14:56, John Karns reorganised a bunch of electrons to form the message:
<SNIP>
> 2) Due to postfix (yuck) sending mail to the bit-bucket, I've tried > bypassing it and specifying procmail as the mda in .fetchmailrc. > > I don't understand why it cites failure to establish an smtp connection > with jkarns at localhost:
Sounds like it's not calling the MDA directly.
> TEMP_FAILURE: Could not initiate SMTP conversation with any hosts: > [localhost (1): Connection refused] > > It would make a little more sense to me to see msgs like this being > generated by postfix on my host, but don't see what POPping from gmail > should be related in any way to an smtp connection.
It looks like it's trying to establish a connection to a local MTA, instead of calling out to procmail. The .fetchmailrc (minus passwords) would be an important source of clues.
Neil Youngman
John Karns [johnkarns at gmail.com]
Thu, 7 Sep 2006 14:11:01 -0500 (COT)
On Thu, 7 Sep 2006, Neil Youngman wrote:
>> It would make a little more sense to me to see msgs like this being >> generated by postfix on my host, but don't see what POPping from gmail >> should be related in any way to an smtp connection. > > It looks like it's trying to establish a connection to a local MTA, instead of > calling out to procmail. The .fetchmailrc (minus passwords) would be an > important source of clues.
Right. See second comment below.
Ok, here it is
1 # Configuration originally created by fetchmailconf 2 # 3 # Global options 4 set syslog 5 set postmaster "jkarns" 6 set no bouncemail 7 # set no spambounce 8 set properties "" 9 10 # Server options 11 skip pop.gmail.com with proto POP3 and options timeout 8 12 # User options 13 user 'johnkarns' there with password 'pw' is 'jkarns' here options fetchall 14 ssl sslfingerprint "59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4" 15 smtphost localhost 16 mda '/usr/bin/procmail -d %T'Notes:
- Changed line 15 to now have the same pseudo FQDN as "myhostname" in
/etc/postfix/main.cf (since the 1st post):
smtphost jkInsp8100.fakedomain.net
- It ocurrs to me that lines 15 and 16 perhaps(?) should be
mutually exclusive; i.e., smtphost should not be used when directing
mail directly to procmail.
- Current revision has line 16 commented out
-- John Karns
Neil Youngman [ny at youngman.org.uk]
Thu, 7 Sep 2006 20:41:39 +0100
On or around Thursday 07 September 2006 20:11, John Karns reorganised a bunch of electrons to form the message:
<SNIP>
> 10 # Server options > 11 skip pop.gmail.com with proto POP3 and options timeout 8 > 12 # User options > 13 user 'johnkarns' there with password 'pw' is 'jkarns' here options fetchall > 14 ssl sslfingerprint "59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4" > 15 smtphost localhost > 16 mda '/usr/bin/procmail -d %T'
<SNIP>
> - It ocurrs to me that lines 15 and 16 perhaps(?) should be > mutually exclusive; i.e., smtphost should not be used when directing > mail directly to procmail.
I wouldn't try to combine them
> - Current revision has line 16 commented out
I thought the objective was to use the procmail mda? At first glance you're going the other way?
Neil
John Karns [johnkarns at gmail.com]
Thu, 7 Sep 2006 15:03:59 -0500 (COT)
On Thu, 7 Sep 2006, Neil Youngman wrote:
> On or around Thursday 07 September 2006 20:11, John Karns reorganised a bunch > of electrons to form the message: > >> 15 smtphost localhost >> 16 mda '/usr/bin/procmail -d %T' > > <SNIP> > >> - It ocurrs to me that lines 15 and 16 perhaps(?) should be >> mutually exclusive; i.e., smtphost should not be used when directing >> mail directly to procmail. > > I wouldn't try to combine them > >> - Current revision has line 16 commented out > > I thought the objective was to use the procmail mda? At first glance you're > going the other way?
Yes, I reverted to putting postfix back in the loop to try to eliminate the error, since the error in the bounce notices was a complaining about not finding an smtp connection. I think I'll wait until after I get a functional & stable configuration before I do any more experimenting. The bounce notices seem to have gone away - for the time being at least. The next step may be to try it without the smtphost line and reinstate procmail.
Since all this is on a mobile host, I'd prefer to have it set up to queue the outgoing mail when I send mail. like back in the days when my mail was cfg'd for a dial-up connection. The queue was flushed after the connection came up. Can a nullmailer handle that scenario? If so, that be the preferred way to go.
-- John Karns
Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 7 Sep 2006 17:41:06 -0400
On Thu, Sep 07, 2006 at 03:03:59PM -0500, John Karns wrote:
> > Since all this is on a mobile host, I'd prefer to have it set up to queue > the outgoing mail when I send mail. like back in the days when my mail was > cfg'd for a dial-up connection. The queue was flushed after the > connection came up. Can a nullmailer handle that scenario? If so, that > be the preferred way to go.
Many nullmailers can; the problem, however, is defining what "connection" means. Is it "every time you dial up"? Then your mail will still be sitting in the queue after you've been on a high-speed Ethernet connection for a week. Is it "once eth0 is up"? Then you'll be trying to toss your mail into the void when you've connected to an isolated LAN, or just peered with another machine.
Truth to tell, I don't know of a good solution to this problem; my nullmailer, "bssmtp", simply queues the mail when I'm off-line, and I just run 'bssmtp -q' when I connect. This is, however, a solution with lots of problems in it. I've considered trying to flush the queue whenever any email is sent, and I've thought about writing a script that looks for any non-local IP (with local ones being defined by the user) in 'netstat -nt' and running it every few minutes via 'cron'. Meanwhile, I'm still doing it manually.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
John Karns [johnkarns at gmail.com]
Sun, 10 Sep 2006 19:32:54 -0500 (COT)
On Thu, 7 Sep 2006, Benjamin A. Okopnik wrote:
> On Thu, Sep 07, 2006 at 03:03:59PM -0500, John Karns wrote: >> >> Since all this is on a mobile host, I'd prefer to have it set up to queue >> the outgoing mail when I send mail. like back in the days when my mail was >> cfg'd for a dial-up connection. The queue was flushed after the >> connection came up. Can a nullmailer handle that scenario? If so, that >> be the preferred way to go.
Oops, I meant to say I'd prefer to have it set up to flush the queue for the outgoing mail when I receive new mail, like back in the days when my mail was cfg'd for a dial-up connection.
> Many nullmailers can; the problem, however, is defining what > "connection" means. Is it "every time you dial up"? Then your mail will > still be sitting in the queue after you've been on a high-speed Ethernet > connection for a week. Is it "once eth0 is up"? Then you'll be trying to > toss your mail into the void when you've connected to an isolated LAN, > or just peered with another machine.
Yes, the number of factors to consider are not diminishing in our as our computing environment continues to sprout more networks.
> Truth to tell, I don't know of a good solution to this problem; my > nullmailer, "bssmtp", simply queues the mail when I'm off-line, and I > just run 'bssmtp -q' when I connect.
That's pretty much what I had in mind.
> This is, however, a solution with lots of problems in it.
The main problem I think might be forgetting to do the flush. Or perhaps being connected via a LAN / gateway which would block port 25.
> I've considered trying to flush the queue > whenever any email is sent, and I've thought about writing a script that > looks for any non-local IP (with local ones being defined by the user) > in 'netstat -nt' and running it every few minutes via 'cron'. Meanwhile, > I'm still doing it manually.
Ok, that sounds interesting. How does that nullmailer handle handshaking problems / failure to send? I've found that postfix, as it's installed on my host, can be somewhat less than informative than what I had been accustomed to via sendmail on SuSE, where problems were usually logged and mailed to postmaster rather than just logged, with the mail being sent to the bit bucket. Although to be fair, it could have been more a problem with fetchmail. So failure to check the mail log frequently can have dire consequences when using postfix, at least in it's Ubuntu stock cfg.
-- John Karns
Benjamin A. Okopnik [ben at linuxgazette.net]
Sun, 10 Sep 2006 22:17:06 -0400
On Sun, Sep 10, 2006 at 07:32:54PM -0500, John Karns wrote:
> On Thu, 7 Sep 2006, Benjamin A. Okopnik wrote: > > > On Thu, Sep 07, 2006 at 03:03:59PM -0500, John Karns wrote: > >> > >> Since all this is on a mobile host, I'd prefer to have it set up to queue > >> the outgoing mail when I send mail. like back in the days when my mail was > >> cfg'd for a dial-up connection. The queue was flushed after the > >> connection came up. Can a nullmailer handle that scenario? If so, that > >> be the preferred way to go. > > Oops, I meant to say I'd prefer to have it set up to flush the queue for > the outgoing mail when I receive new mail, like back in the days when my > mail was cfg'd for a dial-up connection.Hmm, that would be interesting. Some sort of a "biff" function, perhaps? One that's smart enough to distinguish local mail from remote?
> > This is, however, a solution with lots of problems in it. > > The main problem I think might be forgetting to do the flush. Or perhaps > being connected via a LAN / gateway which would block port 25.Actually, since one of the options of 'bssmtp' (the one that I use by default, and the reason that I went with it instead of other nullmailers) is to run a 'preconnect' program before attempting delivery, the port I'm interested in - which is rarely if ever blocked - is 22 (ssh). 25 (smtp) is rapidly becoming unavailable to dynamic-IP/NATted hosts - arguably a good thing - and I've given up relying on it.
Yes, the main problem is forgetting to flush the queue. I haven't yet come up with an algorithm/heuristic for a good automatic trigger.
> > I've considered trying to flush the queue > > whenever any email is sent, and I've thought about writing a script that > > looks for any non-local IP (with local ones being defined by the user) > > in 'netstat -nt' and running it every few minutes via 'cron'. Meanwhile, > > I'm still doing it manually. > > Ok, that sounds interesting. How does that nullmailer handle handshaking > problems / failure to send?
All the mail is queued as soon as 'bssmtp' receives it; whatever doesn't get successfully passed on stays in the queue. In fact, this is the only part of 'bssmtp' that I still have to write: the "retry" section that will warn the sender when the mail in the queue has exceeded a defined period. Other than that, it's still a little less polished than I wish it was, but it works just fine - I've been using it (and tweaking it) for about a year without any problems.
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *