550 5.7.1 email address here ... Relaying denied

[Jay]

I am sure this is not my server but the recipents server that is bouncing the mail back with this error.

Am I right in thinking that their SMTP server is not able to relay the email on their end and sending this back?

Our mail server seems to be working fine.

[nickster]

Have you tried emailing them from another address to see if the same problem occurs? Usually you'd see this error from the server you are sending it from.

[Jay]

no, i'll try it tomorrow.

Maybe they are using a blacklist, we are one 1 blacklist for having a dynamic IP (even thought its a static IP and we have had it for 6 years!)

[badass]

I am sure this is not my server but the recipents server that is bouncing the mail back with this error.

Am I right in thinking that their SMTP server is not able to relay the email on their end and sending this back?

Our mail server seems to be working fine.

correct. However it may be antispam related.

[MaddAussie]

might be worth checking your (and theirs) MX Records as well

[peterb]

If they have controls on the helo and enforce strict compliance with the relevant RFCs, and your server doesn't fully comply with those, then mail will bounce. I did enforce that on my mail server, and while it cut out a huge amount of spam, it resulted in too many false positives (mainly from Outlook clients where there is no provision for setting the helo parameter). However it is a fact that many mailservers do not (or cannot) comply with the RFC - which is a pity...

From my own mailserver (postfix)

warn_if_reject reject_unknown_hostname
warn_if_reject reject_non_fqdn_sender
# reject_invalid_hostname
# reject_unknown_sender_domain
# reject_unknown_client

The first two now only give a warning - enabling those to reject gave pretty good spam control. Enabling the last 3 gave excellent spam control - but too many valid rejections.

So I will be integrating spamassasin 9and probably clam_AV) to filter mail before it is permitted. I should add that I only relay mail originating from within my network, or from authenticated hosts - so these mail controls only apply to inbound mail for users on the network. Relaying via my ISP is explicitly forbidden anyway.

[Lucio]

We've had this problem crop up on and off recently but bouncing back outbound e-mail, since we've turned off ASSP on outgoing e-mail it's not appeared so I'd say your issue is definately anti-spam related.

[Jay]

SORBS have us as a dynamic IP even thouh its full rDNS, static IP and has never changed for over 6 years.

I have put the address in the "CC:" and left the "To:" field blank, lets see how that goes.

[badass]

SORBS have us as a dynamic IP even thouh its full rDNS, static IP and has never changed for over 6 years.

I have put the address in the "CC:" and left the "To:" field blank, lets see how that goes.

Have you tried http://www.au.sorbs.net/cgi-bin/support to get delisted?

[Jay]

Yes but their login system seems broken at the moment so I can't actually see how my application is going.

[Phil_P]

If they have controls on the helo and enforce strict compliance with the relevant RFCs, and your server doesn't fully comply with those, then mail will bounce. I did enforce that on my mail server, and while it cut out a huge amount of spam, it resulted in too many false positives (mainly from Outlook clients where there is no provision for setting the helo parameter). However it is a fact that many mailservers do not (or cannot) comply with the RFC - which is a pity...

From my own mailserver (postfix)

warn_if_reject reject_unknown_hostname
warn_if_reject reject_non_fqdn_sender
# reject_invalid_hostname
# reject_unknown_sender_domain
# reject_unknown_client

The first two now only give a warning - enabling those to reject gave pretty good spam control. Enabling the last 3 gave excellent spam control - but too many valid rejections.

The Outlook issue may be resolved by allowing mail to pass from mynetworks and sasl_authenticated clients before performing the helo tests:

smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_non_fqdn_helo_hostname,
   reject_invalid_helo_hostname,
   permit

Rejecting non_fqdn_helo_hostname catches about 30% of spam alone on my server and I see no false positives. There is absolutely no reason for a properly configured mailserver to helo with a non_fqdn_helo_hostname or invalid_helo_hostname and it's perfectly safe to drop these. Rejecting unknown_sender_domain is a little more risky as temporary DNS failures will lead to rejection - better to temporarily reject (4xx) them until the DNS issues are resolved.

For spamassassin & clamav integration, consider using amavisd as it provides a very powerful solution that's easy to integrate into a postfix server

Which smtp servers don't conform to the RFC? Exim, Postfix, Sendmail, qmail and Exchange all conform to the best of my knowledge and they probably represent 99.9% of legitimate mail. Those that clearly don't conform are shoddy spambots that most folks want to block anyway.

[peterb]

Ohil_P - yes, that is what I do (I didn't post the full section of that aspect of configuration) so I do permit sasl authenticated mail to relay.

I agree that servers are inherently compliant, it is the configuration (or mis-configuration) that is the problem!

Thank you for the amavisd suggestion, I'll look into it.

[Phil_P]

I agree that servers are inherently compliant, it is the configuration (or mis-configuration) that is the problem!

Agreed.

Thank you for the amavisd suggestion, I'll look into it.

Then please allow me to refer you to this guide:

http://wiki.centos.org/HowTos/Amavisd

together with the rather good amavisd documentation:

http://www.ijs.si/software/amavisd/README.postfix.html

Amavisd is nice as it allows a simple method to quarantine spam server side rather than just tagging it (that's all SA is able to do) and leaving it for the end user to filter in their mail client. In my personal experience, SpamAssassin performance is poor out of the box - it takes a little time to tweak the rule sets (and add additional rules), and ideally you need to manually train the Bayesian filters with a corpus of spam and ham (I have found the URIBL and Bayes tests to be highly effective). But once set up correctly it should catch >99% of spam with minimal FPs.

Apologies to the OP for going OT.

[james_d]

Another thing to look into is adding postgrey - I'm now seeing about 1 spam email a day make it as far as spamassassin, before it was running around 20 a day.