I have Zimbra 5.01GA FOSS on Ubuntu 6.06LTS. When I try sending mail from my PDA using the SMTP server (zimbra) I get the following error message:
Feb 8 22:06:24 mail postfix/smtpd: NOQUEUE: reject: RCPT from apn-89-223-245-75.vodafone.hu[126.96.36.199]: 554 5.7.1 <email@example.com>: Relay access denied; from=<firstname.lastname@example.org> to=<email@example.com> proto=ESMTP helo=<Inbox>
How can I enable zimbra to accept the SMTP connection? I think if I were to enable SSL it might work. The PDA is a WindowsMobile6.
Can anyone help me?
The domain that you tried to send an email to "ise.u-szeged.hu" is a non-existent domain. Occasionally what happens when your mail server comes to this situation is it will try to send the email to your DNS server. apn-89-223-245-75.vodafone.hu[188.8.131.52] appears to be your ISP's DNS server...which generally denies SMTP connections ;)
However once you get a valid email to send to you might still run into the issue of the MTA trusted networks. If you want to send emails using your Zimbra server as the SMTP server you will need to either add your phones' IP address to the MTA trusted networks or you will need to set up login for the SMTP server. The first is accessable through the Admin interface in Servers->(server name)->MTA tab->MTA Trusted Networks.
The ise.u-szeged is actually inf.u-szeged so it is a valid domain, the names have been changed before posting.
As for the second part: can I setup maybe SSL authentication for the SMTP connection? Since the PDA allows that. I remember back in case of the old server I had to force 'require authorization' for the SMTP and allow 'relaying when authenticated'. How would this happen in case of Zimbra?
How do I setup SMTP login? I think setting to allow any destination if the user authenticates via SSL would solve my problem, since the log is from the zimbra server and not the ISP. So the request reaches my server it just rejects it, so the mobile carrier does not restrict port 25.
General Settings->MTA->Enable Authentication.
I seem to remember some issues I was having where even though clients had to authenticate they still had to be in the MTA trusted networks to actually send messages through it. I will try to do some more testing later though to verify that.
I have MTA enable auth setup. There is a weird behavior. If I send mail to someone on the domain of the zimbra server it allows the PDA to send it, if the email address is outside the domain it says relay not permitted. Its using the same username/password and the same zimbra server, the only difference is that in the first case the recipient is on the same domain.
Any ideas as to why this is happening?
Again you have to add the IP it is connecting through to the MTA trusted networks for it to not give this error...In my system the only clients that need this type of access are coming from 3 static IP addresses so I can safely just add it....I really would like to know how to set this up in a more general manner. It is something in the postfix configuration but at the moment I don't have time to research it. If I get time before somebody else answers this then I will post my findings.
You should not have to add any external IP address if the user is Authenticating against the Zimbra server, by default an Authenticated user can relay mail through the server.
Originally Posted by ArcaneMagus
You could still have problems that are PDA-specific, however. You might want to try connecting externally using a laptop with a "normal" mail client and see what happens. I have been able to get outside PCs to both check and send mail (POP and IMAP and SMTP), but my Palm T|X with VersaMail steadfastly refuses to work for sending mail. I think it may have to do with VersaMail not handling SSL/TLS right and me being too paranoid to allow cleartext logins, but I have not had time to debug it.
Take-home point, try with PC clients to separate out device-specific problems.
OK. By the way the log reads, your mail program is trying to send as a server to another server instead of a client such as outlook logging in and sending as a client.
The Helo command is producing a reply of Inbox which your postfix server tries to resolve via DNS but can't. Forcing the helo response won't work because any host name you use probably won't resolve.