At 12:25 PM 8/13/01 , Steve Switzer wrote:
fetchmail: no local matches, forwarding to postmaster
...
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<Steve_Switzer(_at_)suth(_dot_)com> SIZE=1299
fetchmail: SMTP< 250 2.1.0 <Steve_Switzer(_at_)suth(_dot_)com>... Sender ok
fetchmail: SMTP> RCPT TO:<postmaster(_at_)localhost>
fetchmail: SMTP< 250 2.1.5 <postmaster(_at_)localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
#fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 f7DF9gZ06792 Message accepted for delivery
I had a very similar configuration fail here two weeks ago after working
for more than a year. All I can figure out is that the Debian update
process brought in a new version that reacted differently. POP3 started
sending everything to the postmaster account, and absolutely nothing else
was changed either at my end or at the ISP.
Switching to ETRN and adding an MX record for the host resolved it, but
"ETRN @domain.com" (seemingly contrary to RFC 1985 section 5.3, but what do
I know) wouldn't work any more either, after having worked on another
disconnected dialup domain a couple of years back. Stil, the command
invocation doesn't seem to correspond to delivery of mail. It appears more
that the frequent queue runners on the ISPs MTA are responsible. Logs are
very sparse even with verbose output.
So, we're living with some pretty long delivery delays until I find another
solution or someone finds what changed and corrects it. That's my hope, at
least.
Jeffrey B. Green Personal Computer Consultant - Las Vegas, Nevada
http://jbgreen.com Networking Las Vegas Since 1986