Topic: Can't collect mail via pop3

[Clive]

I cant collect mail from my pop3 mail box, this is located on a dedicated box.
connecting via a dial-up account via ISDN.

I can send mail no problem via my SMTP server

In the e-mail retrival section, I have setup the following:

E-mail retrieval mode = Multi drop
Delegate mail server = no entry
Secondary mail server is my pop3 mail box like = mail.xyxzz.co.uk

Pop3 username = xxxxx

Pop3 user password = xxxxxxx

But I can never collect the mail from the pop3 box am I missing somthing.

Thank you

Reagrds
Clive (UK)

[guestHH]

Hi Clive,

Which version of MITEL SME are you using ?

Anyway, try this:

Edit the file '/etc/crontab'
You will see that startmail is called several times. Change the word 'startmail' with 'fetchmail'.

Let us know what happens now if you try to collect mail...

Regards,
guestHH

[David Hardy]

I had similar problems with SME 5.1.2 when Freenet upgraded their mailservers:

http://forums.contribs.org/index.php?topic=4578.msg15928#msg15928

I understand that the version of fetchmail in SME 5.5 has been patched, I've downloaded the iso and installed that. It works a treat.

HTH


David.

[Clive]

Hi,

Thanks for the information, I am using version 5.5.

Tried your solution but still cant collect pop3 mail.

Regards

Clive

[Norrie]

Clive,

You're not the only one having this problem.  I'm having this problem with my home server too.  If you look in the bug list you'll see this...

Fetchmail which is triggered on ip-up fails w syntax error
Applies to version: 5.5
Fixed in version:  
Problem: The email-ipup event is calling /etc/fetchmail directly, rather than /etc/startmail. This means that "SMTP" is not defined in the environment, and so the fetchmail configuration is incomplete.
The logs indicate a fetchmail parse error

    fetchmail:-:13: parse error at fetchall

 
Workaround: Manually retrieve mail from the command line
    # /etc/startmail


I think this is the same bug.  However, manually running startmail doesn't work either.
Can anyone offer any more help please?  I'm not sure where to go from here.

System:

SME 5.5
Blades applied
Security update installed
ISDN

Many thanks
Norrie

[David Hardy]

Clive / Norrie,

Have you tried running fetchmail from the command line?

fetchmail -a -p pop3 -v --auth password pop3.isp.co.uk

You should see the interaction between your e-smith and the isp's mail server as a series of messages rushing up the screen.

If it doesn't work at all, see http://www.e-smith.org/bugs/index.php3?op=showBug&bugID=83 which I guess will be fixed in update 3.

In view of the quite crippling nature of this bug, it may be worth considering dropping back to 5.1.2 until its fixed.

Sorry I can't be more positive - being a newbie with only a few months experience myself I'm quite often well out of my depth with all of this!

David.

[Charlie Brady]

David Hardy wrote:

> Have you tried running fetchmail from the command line?
>
> fetchmail -a -p pop3 -v --auth password pop3.isp.co.uk
>
> You should see the interaction between your e-smith and the
> isp's mail server as a series of messages rushing up the
> screen.

Better is to get fetchmail to log more info to syslog:

/sbin/e-smith/db configuration setprop fetchmail \
 Verbosity --verbose
/sbin/e-smith/signal-event email-update

> If it doesn't work at all, see
> http://www.e-smith.org/bugs/index.php3?op=showBug&bugID=83
> which I guess will be fixed in update 3.

That problem is fixed in update 2.

Charlie

[Charlie Brady]

guestHH wrote:

> Edit the file '/etc/crontab'
> You will see that startmail is called several times. Change
> the word 'startmail' with 'fetchmail'.

That's pretty much guaranteed not to work, and will probably make things worse.

Charlie

[Norrie]

Hi,  thanks for your replys.
ok, I did this...

[root@phumper root]# fetchmail -a -p pop3 -v -u myaccount --auth password mail.myisp.net
Enter password for myaccount@myispl.net:
fetchmail: 5.9.0 querying myispl.net (protocol POP3) at Mon 26 Aug 2002 11:14:38 PM BST
fetchmail: POP3< +OK POP3 Ready maxproxy2
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 0 0
fetchmail: No mail for myaccount at myisp.net
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: normal termination, status 1
[root@phumper root]#

I also entered another account's details which started to download mail ok but I terminated the download with ctrl-c because my server isn't set up to retrieve mail from this account.

So, does this mean that fetchmail is working ok and that there's a configuration fault somewhere?

Returning to 5.12 won't help as the ISDN support works in 5.5

Thanks again for the replys but more more help would be great.
All the best

Norrie
8o)

[David Hardy]

OK,

This is my last shot .....

Charlie says its fixed in update 2 - download the rpms and try that.

If it still doesn't work, how about tackling it laterally, switch off multidrop and:

1. Sign up for dynamic dns with mail support at www.no-ip.com ($29 p.a.)
2. Then either
      a) use their ddns client to refresh your status when you go online.
or
      b) have a static IP so their end checks whether or not you are there.
3. Have your email come whooshing in when the other end finds you.

More detail here http://www.no-ip.com/services/mail/backup.

I don't know if this will get you around the bug or just deliver you to the threshold of problems that I have no idea about - perhaps Charlie or someone else with more knowledge than me can comment.

Please note that I have a static IP so have no experience whatsoever with any dynamic IP updating client software at all.

Good Luck!!!!

[Norrie]

Hi.  Thanks for your replys.

This morning I ran...

fetchmail -a -p pop3 -v -u myaccount --auth password mail.myisp.net

And this time a couple of messages were collected.  However, they didn't appear in my webmail page.

I also ran...

/sbin/e-smith/db configuration setprop fetchmail \
Verbosity --verbose
/sbin/e-smith/signal-event email-update

...as Charlie suggested but I don't know what this is supposed to do. (doh!)  I tried to look in the sysinfo file but couldn't find it.

I applied the available blade and update 2 as soon as I set the SME box up and before I entered any mail settings.

So,  is this still a bug and if so should I report this directly to Mitel?

Thanks again

Norrie
8o)

[Laurence Griffiths]

As I posted elsewhere, I am also having this problem. I suggest that you report it to Mitel.

[Charlie Brady]

Norrie wrote:

> fetchmail: No mail for myaccount at myisp.net
...
> So, does this mean that fetchmail is working ok and that
> there's a configuration fault somewhere?

Are you sure that there is mail to collect? It seems from your test above that there isn't.

What do you see when you do:

/sbin/e-smith/db configuration setprop fetchmail \
  Verbosity --verbose
/sbin/e-smith/signal-event email-update
/etc/startmail
tail /var/log/maillog

?

Charlie

[Charlie Brady]

Norrie wrote:

> And this time a couple of messages were collected.  However,
> they didn't appear in my webmail page.

What do you see in /var/log/maillog?
What do you see in /var/log/qmail/current?

The log files are there for a reason

> /sbin/e-smith/db configuration setprop fetchmail \
> Verbosity --verbose
> /sbin/e-smith/signal-event email-update
>
> ...as Charlie suggested but I don't know what this is
> supposed to do.

It tells fetchmail to log more information in /var/log/maillog.

Charlie

[Norrie]

Here is the end of the fetchmail output where the third of three mails are collected...

reading message 3 of 3 (2452 octets)
fetchmail: SMTP> MAIL FROM:
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 13211 bytes 2690
 flushed
fetchmail: POP3> DELE 3
fetchmail: POP3< +OK
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 Good bye.
fetchmail: normal termination, status 0

I'm still unable to collect the mail from a client though.

Charlie> The log files are there for a reason
I know.  I'm just not sure how to find them or what to look for yet. - Thanks!
Does this help you help me?

Thanks again

Norrie
8o)

[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

[Charlie Brady]

Laurence Griffiths wrote:

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

Yes, and in this case that just tells fetchmail to use the default smtphost (localhost) rather than the external interface IP address which we have been specifying (so that anti-relaying rules are used).
Unfortunately the anti-relaying rules aren't very helpful if access is blocked completely (by the private setting).

Regards

Charlie

[Laurence Griffiths]

Charlie and rk,

Thanks for your help. I'll see if they will let me fiddle with the server this afternoon. They just didn't want me to reboot the server while their plant was operating. - For obvious reasons.

I'll tell you what happens as soon as I have tried out Charlie's suggestion.

Cheers

[Charlie Brady]

Laurence Griffiths wrote:

>  They just didn't want me to
> reboot the server while their plant was operating.

I don't think anybody said anything about rebooting the server.

Charlie

[Laurence Griffiths]

I was thinking about changing the configuration away from the "private server and gateway" mode. Configuration changes usually require a reboot, don't they?

[Laurence Griffiths]

And the changes that you have suggested do not require me to reboot the server. - That is what I meant.

Thanks! I'll go and try it out now.

[Laurence Griffiths]

I have tried out Charlie's suggestion. - It didn't work! I got the same error as previously.

I then tried rk's suggestion. - It worked. I'll just make a change to the fetchmail template so that it keeps working.

Thanks guys!

[Norrie]

Hi guys,

Can anyone please point me to the file containing the line:
smtphost $SMTP  ?
I'll try this tonight.

Norrie

[rk]

Norrie:  It's /etc/fetchmail

Please note this is a temporary fix.  If SME 'patches' the original template file, these changes will get reset.  I'm satisfied it will work for now, but this is not an official fix.

rk

[Laurence Griffiths]

I created a custom template, but will delete it if Mitel come up with a fix.

The reason for creating the custom template is that this particular little modification will not be overwritten if any further setting changes are done.

rk, your little modification works beautifully. Thanks!

[Norrie]

Hi folks,

Thanks to the people on this thread my mail is now semi-working.  Commenting out the smtphost $SMTP line in /etc/fetchmail worked for me too.  However, I still have to run /etc/fetcmail manually but I can live with that until an official fix comes out.

Cheers and thanks,
Norrie
8o)

[Laurence Griffiths]

Norrie,

If you apply rk's fix, your SME server should run "/etc/startmail" at whatever intervals you have told it to do in the server manager. Mine does!