Thank you for your help David.

<P>I've been using the open relay test tool at <A href="http://www.abuse.net/relay.html">http://www.abuse.net/relay.html</A> to test my Mercury server.</P> <P>If I rely on the Relaying control checkboxes on the Connection control tab of the SMPT server configuration dialog, I get a response like this:</P> <P><<< 220 my_mercury_server ESMTP server ready. >>> HELO <A href="http://www.abuse.net/">www.abuse.net</A> <<< 250 my_mercury_server Hello, <A href="http://www.abuse.net/">www.abuse.net</A>.</P> <P> Relay test 1 >>> RSET <<< 250 Command processed OK. >>> MAIL FROM:<<A href="mailto:spamtest@abuse.net">spamtest@abuse.net</A>> <<< 250 Sender OK - send RCPTs. >>> RCPT TO:<<A href="mailto:securitytest@abuse.net">securitytest@abuse.net</A>> <<< 553 We do not relay without RFC2554 authentication.</P> <P>Relay test 2 >>> RSET <<< 250 Command processed OK. >>> MAIL FROM:<spamtest> <<< 250 Sender OK - send RCPTs. >>> RCPT TO:<<A href="mailto:securitytest@abuse.net">securitytest@abuse.net</A>> <<< 553 We do not relay without RFC2554 authentication.</P> <P>and so on for several other variations.</P> <P>Alternatively, if I define transaction level filtering rules that allow mail to domains I host, but reject all else:</P> <P>R, "<A href="mailto:*@mydomain.com">*@mydomain.com</A>*", X R, "<A href="mailto:*@myotherdomain.net">*@myotherdomain.net</A>*", X R, "*", R, "554 We do not relay non local mail"</P> <P>then the response I get is quite different:</P> <P><<< 220 my_mercury_server ESMTP server ready. >>> HELO <A href="http://www.abuse.net/">www.abuse.net</A> <<< 250 my_mercury_server Hello, <A href="http://www.abuse.net/">www.abuse.net</A>.</P> <P> Relay test 1 >>> RSET <<< 250 Command processed OK. >>> MAIL FROM:<<A href="mailto:spamtest@abuse.net">spamtest@abuse.net</A>> <<< 250 Sender OK - send RCPTs. >>> RCPT TO:<<A href="mailto:securitytest@abuse.net">securitytest@abuse.net</A>> <<< 554 We do not relay non local mail</P> <P>Relay test 2 >>> RSET <<< 554 Outcast connection - only the QUIT command will be accepted.</P> <P>Now, it's not that I'm concerned about being polite to spammers, but is one response better than the other? </P> <P>Regards, Richard </P>

I'd say a 553 message is better in this case since this is a defined message. 554 is a response you form yourself, and if a standard message exists - go with that.

<p>[quote user="Richard"]... is one response better than the other?[/quote]</p><p>Makes no difference in my book.</p><p>The important thing is that you have given a 500-style response (which is a permanent failure), and ensured that you do not relay. </p><p> (Personally I would use the built-in relaying controls, as they are easier to maintain if you need to change domains etc.) </p><p> </p><p> </p>

<P>Peter & Paul, thank you for your help. </P> <P>Do you know what it means by an 'Outcast connection' ?</P> <P>I assume there is still a TCP connection, otherwise the sender wouldn't still have the option of sending a QUIT.</P> <P mce_keep="true"> </P>

An "outcast" connection is one that has been marked as bad internally. The only command that Mercury will accept from a connection in the "outcast" state is "QUIT" - no mail delivery is possible. A connection can only become outcast through either a transaction filtering rule or a compliance failure. In v4.5, the word "outcast" has changed to "shunned" to indicate more forcefully that we don't like the connection. [;)] Cheers! -- David --