Carlos Sousa wrote:
Quite how the password gets from the pop3 reference to the smtp bit, I don't understand...I don't see how it can. This config shows how fetchmail *gets* mail using pop3 authentication, the *sending* of mail has nothing to do with it. But then, thats probably what the OP meant. I don't think ISPs implement smtp authentication, they just perform an ip check to allow anybody on their network to use their smtp servers.
I have a website hosted out in CA (I'm in NY so obviously I'm not using them for home connectivity & am not on their network) which runs exim 3.36 #1. Authentication for outgoing mail seems to be based on whether I've logged in to the POP/IMAP server:
> telnet mail.mydomain.com 25 220-mail.myhost.com ESMTP Exim 3.36 #1 Sun, 15 Dec 2002 19:50:25 -0800 220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail. [MAIL FROM: kenneth@mydomain.com] 250 <kenneth@mydomain.com> is syntactically correct [RCPT TO: kenneth@myotherdomain.net] 550-Host 66-108-241-172.nyc.rr.com [66.108.241.172] is not permitted 550-to relay through mail.myhost.com.550-Perhaps you have not logged into the pop/imap server in the last 30 minutes.
550-You may also have been rejected because your ip address 550-does not have a reverse DNS entry. 550 relaying to <kenneth@mydomain.com> prohibited by administratorI noticed this a couple of weeks ago & have been intending to look into it, but haven't had time.. I don't know if it's normal authenticating exim behavior to fall back on POP/IMAP if it doesn't get the SMTP AUTH command or if it's some custom scheme, but unless I'm reading this all wrong it certainly looks possible that fetchmail is opening the relay for Pigeon