Filter invalid commands

PaulW

posted Jul 7 '12 at 12:06 pm

[quote user="Kevin Hastings"]This makes me wonder if there is a way to limit the 501's to 1 or 2 before the 554 is returned.[/quote]

No, it is built-in to Mercury.

[quote]Am I loosing the plot?[/quote]

Only you can answer that!! But I wouldn't spend any time chasing down these connections - there are more important mail-admin tasks to do. :)

<P>[quote user="Kevin Hastings"]This makes me wonder if there is a way to limit the 501's to 1 or 2 before the 554 is returned.[/quote]</P> <P>No, it is built-in to Mercury.</P> <P>[quote]Am I loosing the plot?[/quote]</P> <P>Only you can answer that!!&nbsp; But I wouldn't spend any time chasing down these connections - there are more important mail-admin tasks to do. :)</P>

Kevin Hastings

posted Jun 30 '12 at 6:15 am

T 20120626 113131 4fe5770e Connection from 208.122.116.51

T 20120626 113131 4fe5770e GET / HTTP/1.0

T 20120626 113131 4fe5770e

T 20120626 113135 4fe5770e Connection closed with 208.122.116.51, 4 sec. elapsed.

If I add:

H, "GET*", DS

to transflt.mer will that stop this kind of transaction quicker? because there is no HELO greeting so I am unsure. Also if it won't work could you suggest something else that might?

Thanks.

<div>T 20120626 113131 4fe5770e Connection from 208.122.116.51</div><div>T 20120626 113131 4fe5770e GET / HTTP/1.0</div><div>T 20120626 113131 4fe5770e&nbsp;</div><div>T 20120626 113135 4fe5770e Connection closed with 208.122.116.51, 4 sec. elapsed.</div><div>&nbsp;</div><div>If I add:</div><div>H, "GET*", DS</div><div>to transflt.mer will that stop this kind of transaction quicker? because there is no HELO greeting so I am unsure. &nbsp;Also if it won't work could you suggest something else that might?</div><div>&nbsp;</div><div>Thanks.&nbsp;</div>

Rolf Lindby

posted Jun 30 '12 at 4:48 pm

Transaction filtering is event bound, so I expect it will fail as it's not a HELO command. It would probably not be possible to catch with an event daemon either as a completed HELO event is needed to start reviewing raw command lines.

Mercury isn't doing much while waiting for the connection to timeout though so I'm not sure this really is a problem. Still it could be possible to catch this kind of annoyance (someone scanning all open ports for a HTTP server) with a firewall that has built-in protocol inspectors.

/Rolf

<p>Transaction filtering is event bound, so I expect it will fail as it's not a HELO command. It would probably not be&nbsp;possible&nbsp;to catch with an event daemon either as a completed HELO event is needed to start reviewing raw command lines.</p><p>Mercury isn't doing much while&nbsp;waiting&nbsp;for the connection to timeout though so I'm not sure this really is a problem. Still it could be possible to catch this kind of annoyance (someone scanning all open ports for a HTTP server) with a firewall that has built-in protocol inspectors.</p><p>/Rolf&nbsp;</p>

Kevin Hastings

posted Jul 6 '12 at 3:59 am

Thanks,

My firewall can only distinguish TCP not SMTP [:(]

<p>Thanks,</p><p>&nbsp;My firewall can only&nbsp;distinguish TCP not SMTP&nbsp;&nbsp;&nbsp;[:(]</p>

PaulW

posted Jul 6 '12 at 10:56 am

[quote user="Kevin Hastings"]My firewall can only distinguish TCP not SMTP[/quote]

SMTP is TCP - it is just a sequence of commands on the correct port.

Probably the only way to block these completely is to stop the IP address from communicating with you. That may be possible at your firewall, but would be timesome to maintain, and likely to be error-prone. As Rolf says, they aren't harmful and Mercury is dealing with them.

<P>[quote user="Kevin Hastings"]My firewall can only&nbsp;distinguish TCP not SMTP[/quote]</P> <P>SMTP <STRONG>is</STRONG> TCP - it is just a sequence of commands on the correct port.</P> <P>Probably&nbsp;the only way to block these completely is to stop the IP address from communicating with you.&nbsp; That may be possible at your firewall, but would be timesome to maintain, and likely to be error-prone.&nbsp; As Rolf says, they aren't harmful&nbsp;and Mercury is dealing with them.</P>

Kevin Hastings

posted Jul 6 '12 at 9:59 pm

Yes, sorry I wasn't clear, of course SMTP is TCP, but so is HTTP, I meant my firewall can't look deeper than TCP.

I know now they aren't doing any harm, but I feel like they are challenging me to find a way to cut them out completely .

If I put my ip address and port as a web browser's proxy - this is what I get from any request from the browser (in the browser):

220 MERCURY ESMTP server ready.

501 Syntax error in parameters or arguments.

554 Too many bad or unrecognized SMTP commands - terminating connection.

This makes me wonder if there is a way to limit the 501's to 1 or 2 before the 554 is returned.

Am I loosing the plot?

<p>Yes, sorry I wasn't clear, of course SMTP is TCP, but so is HTTP, I meant my firewall can't look deeper than TCP.</p><p>I know now they aren't doing any harm, but I feel like they are challenging me to find a way to cut them out completely .</p><p>If I put my ip address and port as a web browser's proxy - this is what I get from any request from the browser (in the browser):</p><pre style="word-wrap: break-word; white-space: pre-wrap; ">220 MERCURY ESMTP server ready. 501 Syntax error in parameters or arguments. 501 Syntax error in parameters or arguments. 501 Syntax error in parameters or arguments. 501 Syntax error in parameters or arguments. 501 Syntax error in parameters or arguments. 501 Syntax error in parameters or arguments.&nbsp;</pre><p><span style="white-space: pre-wrap; ">554 Too many bad or unrecognized SMTP commands - terminating connection.</span>&nbsp;</p><p>&nbsp;This makes me wonder if there is a way to limit the 501's to 1 or 2 before the 554 is returned.</p><p>Am I loosing the plot?&nbsp;</p><p>&nbsp;</p>

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history