On 2/14/2011 5:32 AM, Georg Schönweger wrote:
Yes the server is using authentication on the relay-host.
/etc/postfix/main.cf:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes

it is just only this particular recipient where it doesn't work!

- Georg

Am 14.02.2011 11:05, schrieb Reindl Harald:
Is your server using authentication on the relay-host?
If not this MUST NOT work because if it would work the
relayserver coul be used from everybody out there for spam

Am 14.02.2011 08:59, schrieb Georg Schönweger:
Hi,

yesterday i received a failure-notice;
Remote host said: 554 5.7.1<i...@domain.com>: Relay access denied -->
this is the error-message which i received from the final recipient.
The email was send from our webserver. The webserver (postfix) sends the
email via relayhost (another external postfix Server) to the world outside.
Does this mean that the email provider from the recipient doesn't allow
the use of relayhosts? Is it generally better to not use relayhosts?
..we had problems with spam some years ago if we sent mails directly
with postfix, so we used our external email provider as relayhost. But i
think this was because we didn't have a valid RDNS entry. So should i
switch off the relayhost?
You get "Relay access denied" when you're contacting a RECEIVING mail server with a message that that mailserver doesn't want to handle, because it's not the authoritative destination for that domain. Nothing here implies anything wrong with a legitimate relay that you're using on the SENDING side. If that works at all, then it's fine. Either you're authorized to relay through it or not. Using/not using that is a separate decision altogether. The receiver doesn't care how many relays a message has been through. It cares only about two things: 1) is the most recent hop blacklisted; 2) do I (the receiver) handle the recipient address (domain and username) either as a relay or as the final destination.

You are failing test 2) it seems.

Main question -- is the receiving mail server in question listed as a current MX for domain.com? (Or is your webserver somehow accessing stale MX...) But If the MX indeed is current, the receiving server is probably just misconfigured and you can do nothing but contact the remote site's postmaster. (By phone perhaps, depending on the level of brokenness?!? :-))

-Daniel

Reply via email to