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
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
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
--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,
never
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
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 after
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
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 from a
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 a
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
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
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
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
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 it
- 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 all
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
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
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
:
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
Hi,
We've recently seen a large increase in SPAM volume, and although SA is taking
care of the classification, a simple analysis of the messages shows that most
have a pattern, in that everything which has a particular user's e-mail address
in the subject is SPAM.
Looking at the relay IP
20 matches
Mail list logo
