Topic: Can't collect mail via pop3

[Norrie]

PS...

The collected mail is landing in /home/e-smith/Maildir/new

Thanks
Norrie
8o)

[Laurence Griffiths]

I have tried the same thing....
What I get is...

[root@tserv1 root]# tail /var/log/maillog
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3< .
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3> RETR 1
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3< +OK 2358 octets follow.
Aug 28 08:32:47 tserv1 fetchmail[4102]: reading message 1 of 59 (2358 octets)
Aug 28 08:32:47 tserv1 fetchmail[4102]: SMTP connect to 211.28.100.142 failed
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3> QUIT^M
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3<
Aug 28 08:32:47 tserv1 fetchmail[4102]: SMTP transaction error while fetching from mail.optusnet.com.au
Aug 28 08:32:47 tserv1 fetchmail[4102]: Query status=10 (SMTP)
Aug 28 08:32:47 tserv1 fetchmail[4102]: normal termination, status 10
[root@tserv1 root]#

[Laurence Griffiths]

And....

[root@tserv1 root]# tail /var/log/qmail/current
@400000003d6b2bb034a05404 new msg 3817476
@400000003d6b2bb034a6d7fc info msg 3817476: bytes 844 from qp 2679 uid 400
@400000003d6b2bb034e54474 starting delivery 8: msg 3817476 to local USERNAME@tserv1.DOMAIN.com.au
@400000003d6b2bb034e9d854 status: local 2/10 remote 0/20
@400000003d6b2bb1015364c4 delivery 7: success: forward:_qp_2679/did_0+0+1/
@400000003d6b2bb1015af25c status: local 1/10 remote 0/20
@400000003d6b2bb101640694 end msg 3817474
@400000003d6b2bb101a7c26c delivery 8: success: did_1+0+0/
@400000003d6b2bb101aebf7c status: local 0/10 remote 0/20
@400000003d6b2bb101b75e84 end msg 3817476

[Laurence Griffiths]

This is what I get from fetchmail:

[root@tserv1 root]# fetchmail -a -p pop3 -v -u myaccount --auth password mail.optusnet.com.au
File /root/.fetchmailrc must have no more than -rwx--x--- (0710) permissions.
[root@tserv1 root]#

[Laurence Griffiths]

If I type "mv .fetchmailrc .fetchmailrc.old" and then the following...

[root@tserv1 root]# fetchmail -a -p pop3 -v -u myaccount --auth password mail.opt
usnet.com.au
Enter password for trussfab@mail.optusnet.com.au:
fetchmail: 5.9.0 querying mail.optusnet.com.au (protocol POP3) at Wed 28 Aug 200
2 09:01:07 AM EST
fetchmail: POP3< +OK POP3 Ready mail011.syd.optusnet.com.au
fetchmail: POP3> USER myaccount
fetchmail: POP3< +OK USER myaccount set
fetchmail: POP3> PASS *
fetchmail: POP3< +OK You are so in
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 787
1 message for trussfab at mail.optusnet.com.au (787 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK POP3 clients that break here, they violate STD53.
fetchmail: POP3< 1 787
fetchmail: POP3< .
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 787 octets follow.
reading message 1 of 1 (787 octets)
fetchmail: SMTP< 220 tserv1.mydomain.com.au mailfront ESMTP
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-tserv1.mydomain.com.au
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250 PIPELINING
fetchmail: SMTP> MAIL FROM: BODY=8BITMIME
fetchmail: SMTP< 250 Sender accepted.
fetchmail: SMTP> RCPT TO:
fetchmail: SMTP< 250 Recipient accepted.
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 End your message with a period.
#****fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 Accepted message qp 4677 bytes 1014
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Deleted.
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Bye-bye.
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 Good bye.
fetchmail: normal termination, status 0
[root@tserv1 root]#

The message is forwarded to admin.

[Charlie Brady]

Laurence Griffiths wrote:

> If I type "mv .fetchmailrc .fetchmailrc.old" and then the
> following...
> [root@tserv1 root]# fetchmail -a -p pop3 -v -u myaccount
> --auth password mail.opt

Creating a .fetchmailrc and running fetchmail from the command line is just going to confuse things further.

> fetchmail: SMTP> MAIL FROM: BODY=8BITMIME
> fetchmail: SMTP< 250 Sender accepted.
> fetchmail: SMTP> RCPT TO:
...
> The message is forwarded to admin.

Mail to "root" is always forwarded to admin.

Charlie

[Laurence Griffiths]

Yeah! But the email message in question wasn't sent to the "root". It was sent to one of the users of the system.

[Laurence Griffiths]

But does this tell you anything?

[root@tserv1 root]# tail /var/log/maillog
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3< .
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3> RETR 1
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3< +OK 2358 octets follow.
Aug 28 08:32:47 tserv1 fetchmail[4102]: reading message 1 of 59 (2358 octets)
Aug 28 08:32:47 tserv1 fetchmail[4102]: SMTP connect to 211.28.100.142 failed
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3> QUIT^M
Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3<
Aug 28 08:32:47 tserv1 fetchmail[4102]: SMTP transaction error while fetching from mail.optusnet.com.au
Aug 28 08:32:47 tserv1 fetchmail[4102]: Query status=10 (SMTP)
Aug 28 08:32:47 tserv1 fetchmail[4102]: normal termination, status 10
[root@tserv1 root]#

[Charlie Brady]

Laurence Griffiths wrote:
 
> Yeah! But the email message in question wasn't sent to the
> "root". It was sent to one of the users of the system.

In that particular case, it was because you ran fetchmail from the command line. When fetchmail is run from /etc/startmail, it will either deliver to users, or will deliver to postmaster, if fetchmail cannot guess who to deliver it to. Fetchmail's multi-drop mode is inherently unreliable. Please read the fetchmail FAQ to understand why.

Do you have have a "sort header" defined in your mail retreival configuration? If not, then adding one may help with correct delivery, if a suitable header has been added by your ISP.

Charlie

[Charlie Brady]

Laurence Griffiths wrote:
>
> But does this tell you anything?
...
> Aug 28 08:32:47 tserv1 fetchmail[4102]: SMTP connect to
> 211.28.100.142 failed
> Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3> QUIT^M
> Aug 28 08:32:47 tserv1 fetchmail[4102]: POP3<
>
> Aug 28 08:32:47 tserv1 fetchmail[4102]: SMTP transaction
> error while fetching from mail.optusnet.com.au

Yes, it shows a problem connecting to the SMTP daemon.  What mode is your server configured in?

Charlie

[Laurence Griffiths]

My server is configured as a "Private Server and Gateway".

[Laurence Griffiths]

Thanks for that Charlie.

Charlie Brady wrote:
"Do you have have a "sort header" defined in your mail retreival configuration? If not, then adding one may help with correct delivery, if a suitable header has been added by your ISP."

I realise that multidrop is unreliable. The boss-man wants it that way. In the past, using SME 5.0, ordinary email messages have gone through to their correct recipients. Mailing list messages have gone through to the administrator who then passed them on to their intended recipients. The default sorting method has been used. I have suggested using the "Standard" method of email retrieval, but the boss-man doesn't want to fork out the money for a permanent connection with a fixed IP address.

My problem is not that emails are going through to the incorrect recipients, it is that mail is not getting picked up at all from the Optusnet mailbox.

The server is being run as a "Private Server and Gateway". It has always run this way. Do you think that it would help to run it in a different mode?

[rk]

I don't know if this is a 'fix' or not, but I found that if I added a '#' to the beginning of the line:
#           smtphost $SMTP

That the parse error went away.  It looks like my mail is back up and running temporarily.

Hope it helps...
rk

[Laurence Griffiths]

Thanks for that. I'll give it a try tomorrow which is when I can next get my paws on the server.

One question about that..... Can you still send email? "#" treats the rest of the line as a comment!

[Charlie Brady]

Laurence Griffiths wrote:

> The server is being run as a "Private Server and Gateway". It
> has always run this way. Do you think that it would help to
> run it in a different mode?

Yes, I've been thinking about your problem, and the evidence adds up to there being a new problem with fetchmail and "private server and gateway mode". If it's what I think it is, this will fix the problem:

/sbin/e-smith/db configuration setprop xxx access public
/sbin/e-smith/signal-event remoteaccess-update

where xxx is smtpfront-qmail for 5.5 and smtpd for 5.1.x.

You won't have lost any mail, it will still be in the mailbox at the ISP.

Charlie