Yes, however, certain 5xx responses I do not see ANY reason for allowing a
client to recover, for example, if the client was relaying through a
blacklisted IP.. there is NOTHING the client can do to change that during the
same conversation, thus it makes zero sense to allow it to recover or
pot
Paul Murphy wrote:
You are correct - Sendmail doesn't log them by default. If you get a null
connection, that gets logged. If the sender is refused by check_rcpt, that gets
logged. But invalid commands, including those generated after a sender ignores
a 5xx error and carries on through the DATA p
Jim,
> Looking at my log files I do NOT see the issue which you describe where a
> client continues to send data regardless of the commands returned. Of course
> I am not sure how much, if any, of that would be logged. I suspect only the
> initial connect and the quit would generate a log antry
The key word in that statement from RFC 2821 is SHOULD which has a very
specific meaning in an RFC as defined in RFC 2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full im
Aleksander,
> Probably not a good idea, since you don't know how big is remote network
> block. It might be something like /24, but it also might be something
> like /29. If you blindly assume it is /24, you'll get the spammer
> blocked (maybe, it just might be that one of your users had .for
On Wed, 3 Nov 2004, Joseph Brennan wrote:
>
>
> Outlook does that too. You can end up with tens of thousands of
> connections a day trying to send the same couple of messages,
> never mind the 5xx responses.
There are also some broken MTAs which respond to a 4xx as if it were a
5xx and drop the
David F. Skoll wrote:
On Wed, 3 Nov 2004, Aleksandar Milivojevic wrote:
This is because we have only "error" built-in mailer in Sendmail. If we
had "disconnect" built-in mailer, things would probably be a bit different.
From reading the Sendmail source code, it looks like Sendmail 8.13.1
treats
Paul Murphy wrote:
I'd also be interested in implementing a block based on address range check, so
perhaps if more than 10 SPAM messages which scored over 10 were received from an
address block, then the known or estimated range of SPAM senders in that block
would be blacklisted using IPTables, wit
On Wed, 3 Nov 2004, Aleksandar Milivojevic wrote:
> This is because we have only "error" built-in mailer in Sendmail. If we
> had "disconnect" built-in mailer, things would probably be a bit different.
>From reading the Sendmail source code, it looks like Sendmail 8.13.1
treats a 421 reply code
James Ebright wrote:
I am not sure you understand how an SMTP conversaation takes place... it is
my understanding that the client cannot "ignore" a 5xx response and continue
blasting data... since the server will not talk to a client after sending a
5xx response and closes the connection. Thus a
James,
> I am not sure you understand how an SMTP conversaation takes
> place... it is my understanding that the client cannot
> "ignore" a 5xx response and continue blasting data... since
> the server will not talk to a client after sending a 5xx
> response and closes the connection. Thus aft
Paul,
No, I understand your point, it is just that by using IP tables to drop the
connection _very_ few packets before sendmail (postfix, etc) would (if using
your own DNSRBL, i.e. install the software and lock it down for your own use
yourself...) you do not gain alot and loose RFC compliancy.
--On Tuesday, November 2, 2004 3:51 PM + Paul Murphy
<[EMAIL PROTECTED]> wrote:
We're dealing with spammers who either ignore the 5xx response and
keep trying,
Outlook does that too. You can end up with tens of thousands of
connections a day trying to send the same couple of messages,
neve
James,
> Seems to me this would be much better served implemented as a DNSRBL than a
> iptables solution. By using your own DNSRBL, you would have a scalable, RFC
> compliant solution that still drops the connection well before the "data"
> phase and before any mimedefang/SA processing, if you
Seems to me this would be much better served implemented as a DNSRBL than a
iptables solution. By using your own DNSRBL, you would have a scalable, RFC
compliant solution that still drops the connection well before the "data"
phase and before any mimedefang/SA processing, if you implement the DN
Seems to me this would be much better served implemented as a DNSRBL than a
iptables solution. By using your own DNSRBL, you would have a scalable, RFC
compliant solution that still drops the connection well before the "data"
phase and before any mimedefang/SA processing, if you implement the DN
Alberto,
> You run the risk of starting a DoS attach against your own box.
> The RFC's state that senders should keep trying for ~5 days
>
> Quote "
> : Chances are that you would get more DoS by new connections constantly
> : coming in, than by 5xx responses causing at least protocol-compliant
>
Chris,
> Watch out for mail services that forward e-mail to your
> users. Think this:
> A user has an MSN account that gets a lot of spam, and
> that user sets his MSN account to forward to his local
> mailbox. Blam! You no longer receive _any_ email from MSN.
Accepted - that's why I'd only
Greetings,
You run the risk of starting a DoS attach against your own box.
The RFC's state that senders should keep trying for ~5 days
Quote "
: Chances are that you would get more DoS by new connections constantly
: coming in, than by 5xx responses causing at least protocol-compliant
: senders t
- Original Message -
From: "Paul Murphy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 01, 2004 10:26 AM
Subject: [Mimedefang] Blocking spam senders using IPTables?
> Given that real mail from these sites is unlikely, I'm tempted to
implement a
> system of blocking a
On 11/2/2004 07:12, Paul Murphy wrote:
> Just a check - is everyone so stunned by my suggestion that they can't speak, or
> too busy laughing at something in it?
I thought it looked like a pretty interesting idea and was waiting to hear
more. Do please relate your experience with it if you give i
Just a check - is everyone so stunned by my suggestion that they can't speak, or
too busy laughing at something in it?
Best Wishes,
Paul.
__
Paul Murphy
Head of Informatics
Ionix Pharmaceuticals Ltd
418 Science Park, Cambridge, CB4 0PA
Tel. 01223 4
22 matches
Mail list logo
