Steve Wray schrieb:
Tilman Schmidt wrote:
[...]
So dropping mail into the bitbucket is not an alternative. I have to
either reject it or deliver it.
Wow.
So... the default, unpatched build of qmail is quite popular in Germany?
I won't enter that minefield. :-)
But unpatched qmail is
Tilman Schmidt wrote:
Am 11.08.2008 12:05 schrieb Ian Eiloart:
In fact, if you accept the email, then silently discard it, then you
effectively endorsing the validity of the email. You'll be improving
the reputation of the original sender in the eyes of the ISP.
Worse, it can even be a
On Mon, 11 Aug 2008 11:33:00 -0400 (EDT), Charles Gregory wrote:
it concerns me as to whether these remarks about 'big name' non-compliant
MTA's still apply specifically to greylisting. I mean, I can't really
imagine a 'big' (fortune 500?) company having an MTA that does not attempt
to resend
On 11.08.08 09:30, Dennis Peterson wrote:
There are some big names that play badly with greylisting. They play
badly with greet-pause, too. A problem I've seen with greylisting is the
round-robin MTA pool. Each is told in turn to come back later and if the
pool is large it can take a long time
Am 11.08.2008 12:05 schrieb Ian Eiloart:
In fact, if you accept the email, then silently discard it, then you
effectively endorsing the validity of the email. You'll be improving the
reputation of the original sender in the eyes of the ISP.
Worse, it can even be a punishable offense. At least
--On 8 August 2008 13:06:00 -0400 rick pim [EMAIL PROTECTED] wrote:
Gerard writes:
Employing 'greylisting' would vastly improve the chances of eliminating
the acceptance of SPAM at the MTA level.
it certainly does. unfortunately, in practice, one of the
prime advantages of greylisting
--On 8 August 2008 14:16:49 -0400 David F. Skoll [EMAIL PROTECTED]
wrote:
Tilman Schmidt wrote:
telnet isps-smtp-server 25
In my experience that's very unusual behaviour for a virus.
The vast majority try to connect directly to the recipient's MX.
I see both.
Regardless, your
Hi there,
On Mon, 11 Aug 2008 Ian Eiloart wrote:
RFC2821 defines the behaviour of an MTA, and anything that breaks
the standard can't expect to deliver email. That's our policy here.
Hehe, I bet you'd change that policy pretty sharpish if the people
sending the emails wanted to give you
Ian Eiloart writes:
--On 8 August 2008 13:06:00 -0400 rick pim [EMAIL PROTECTED] wrote:
in practice, one of the
prime advantages of greylisting -- the fact that it will never
block 'real' mail -- turns out, um, not to be true. there are so many
standards-noncompliant MTAs out there
On Mon, 11 Aug 2008, rick pim wrote:
prime advantages of greylisting -- the fact that it will never
block 'real' mail -- turns out, um, not to be true. there are so many
standards-noncompliant MTAs out there
.. some of the offenders are high profile, fortune-500 companies.
Charles Gregory writes:
but at
least please tell me there isn't a 'big' company out there that is failing
to handle 4xx codes properly (holding breath)
does IBM count?
their canadian arm was a problem for a while and i had to whitelist
their outgoing MTA. this has since been fixed, but
Charles Gregory wrote:
Could I just clarify this discussion? It started out with a specific
comment about greylisting, which I am preparing to implement. So naturally
it concerns me as to whether these remarks about 'big name' non-compliant
MTA's still apply specifically to greylisting. I
Charles Gregory wrote:
On Mon, 11 Aug 2008, rick pim wrote:
prime advantages of greylisting -- the fact that it will never
block 'real' mail -- turns out, um, not to be true. there are so many
standards-noncompliant MTAs out there
.. some of the offenders are high profile,
-Original Message-
There are some big names that play badly with greylisting. They play
badly with greet-pause, too. A problem I've seen with
greylisting is the
round-robin MTA pool. Each is told in turn to come back later
and if the
pool is large it can take a long time to
On Mon, 11 Aug 2008, David F. Skoll wrote:
S:220 smtp.example.net Go ahead
C:MAIL FROM:[EMAIL PROTECTED]
S:220 Sender OK
C:RCPT TO:[EMAIL PROTECTED]
S:451 Greylisted... try again later
C:RCPT TO:[EMAIL PROTECTED]
S:451 Greylisted... try again later
C:DATA
S:500 Need recipient first
Charles Gregory wrote:
Non-compliant 'helo's and all that, but at least please tell me there
isn't a 'big' company out there that is failing to handle 4xx codes
properly (holding breath)
Try:
hotmail.com
bigpond.com
optusnet.com.au
yahoo.com [for groups particularly...]
Greylisting is
Hi all,
On Sat, 9 Aug 2008 [EMAIL PROTECTED] wrote:
all kinds of different takes on it :)
FWIW, as you know by now I'm in the 'let them know there's a problem'
camp. But, well, it was just a suggestion. It was interesting so see
the response to my post, obviously there are some strong
G.W. Haywood wrote:
On the point about accepting and then rejecting, no, you misunderstand
the SMTP conversation. It is perfectly possible to read an entire mail
message and yet still reject it.
Presuming you mean the message is read up to the final cr.cr, this is
true. It is the last
Hi there,
On Fri, 8 Aug 2008 jef moskot wrote:
Re: simplest replacement for ancient amavis-perl
Currently, we accept all infected mail, and quietly quarantine it.
May I suggest that you quarantine it, BUT STILL REJECT IT after it
has been read (and recorded) in its entirety? You're making a
G.W. Haywood wrote:
Currently, we accept all infected mail, and quietly quarantine it.
May I suggest that you quarantine it, BUT STILL REJECT IT after it
has been read (and recorded) in its entirety?
No, please don't do that for viruses. If they are being transmitted
by a real SMTP client,
David F. Skoll wrote:
G.W. Haywood wrote:
Currently, we accept all infected mail, and quietly quarantine it.
May I suggest that you quarantine it, BUT STILL REJECT IT after it
has been read (and recorded) in its entirety?
No, please don't do that for viruses. If they are being
[EMAIL PROTECTED] wrote:
If done during the SMTP conversation the only thing that is going to
see backscatter is the thing that sent it.
Which is why I qualified my reply with if the sending relay is a valid
SMTP client.
I am under the opinion that a message should never
be silently
new mail in /var/spool/mail/root
Thanks,
Parveen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David F.
Skoll
Sent: Thursday, August 07, 2008 2:28 PM
To: ClamAV users ML
Subject: Re: [Clamav-users] simplest replacement for ancient amavis-perl
jef moskot
On Fri, Aug 08, 2008 at 03:20:01PM CEST, [EMAIL PROTECTED] said:
David F. Skoll wrote:
G.W. Haywood wrote:
Currently, we accept all infected mail, and quietly quarantine it.
May I suggest that you quarantine it, BUT STILL REJECT IT after it
has been read (and recorded) in its
On Fri, Aug 08, 2008 at 09:25:19AM -0400, David F. Skoll wrote:
I am under the opinion that a message should never
be silently blackholed.
I used to share that opinion, but no longer do for viruses. If you
turn off Clam's dubious Phishing options, the odds of a false-positive
from Clam
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
If done during the SMTP conversation the only thing that is going to
see backscatter is the thing that sent it.
Which is why I qualified my reply with if the sending relay is a valid
SMTP client.
Maybe we are just arguing semantics but
On Fri, 8 Aug 2008 13:31:24 +0100 (BST)
G.W. Haywood [EMAIL PROTECTED] wrote:
Currently, we accept all infected mail, and quietly quarantine it.
May I suggest that you quarantine it, BUT STILL REJECT IT after it
has been read (and recorded) in its entirety? You're making a rod
for your own
Parveen Malik wrote:
Hi all,
I need to open ports for Clamav database update, but since yesterday it
seems that IP address are changing every hour.. Can you guys please let
me know what should I do to resolve this issue.
Sending you ping output.
[EMAIL PROTECTED] root]# ping
[EMAIL PROTECTED] wrote:
Which is why I qualified my reply with if the sending relay is a valid
SMTP client.
Maybe we are just arguing semantics but anything that connects to
my mail server and speaks RFC821 is valid. I might not like what
it feeds me but that is what ClamAV/SpamAssassin
On Fri, 8 Aug 2008, David F. Skoll wrote:
G.W. Haywood wrote:
You're making a rod for your own back if you accept bad mail. The
sender will sell the recipients' addresses to all his spammer friends
and you'll just get more of it.
In my experience, spammers do not bother cleaning their
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
Which is why I qualified my reply with if the sending relay is a valid
SMTP client.
Maybe we are just arguing semantics but anything that connects to
my mail server and speaks RFC821 is valid. I might not like what
it feeds me but that is
[EMAIL PROTECTED] wrote:
[...]
What backscatter? If done at SMTP the only person that should be
notified is the sender.
I see. And it's impossible for a virus to forge MAIL FROM:, is it?
Regards,
David.
___
Help us build a comprehensive ClamAV
: Re: [Clamav-users] simplest replacement for ancient amavis-perl
Parveen Malik wrote:
Hi all,
I need to open ports for Clamav database update, but since yesterday
it
seems that IP address are changing every hour.. Can you guys please
let
me know what should I do to resolve this issue
[EMAIL PROTECTED] wrote:
No, is is trivial for anyone to forge mail from headers but that is
irrelevant when virus filtering is done at the SMTP level. You don't
send the rejection to the address in the mail from. You send the
rejection to the server/client that sent you the message because
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
No, is is trivial for anyone to forge mail from headers but that is
irrelevant when virus filtering is done at the SMTP level. You don't
send the rejection to the address in the mail from. You send the
rejection to the server/client that sent
[EMAIL PROTECTED] wrote:
No, I did not say that. I said it was trivial. I am just pointing out that
it is irrelevant while the SMTP conversation is still going on. It is
impossible(mostly) to forge the IP the message is being sent from if there
is a live SMTP conversation going on and
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
No, I did not say that. I said it was trivial. I am just pointing out that
it is irrelevant while the SMTP conversation is still going on. It is
impossible(mostly) to forge the IP the message is being sent from if there
is a live SMTP
[EMAIL PROTECTED] wrote:
No need to be condescending about it. I have no problem taking it off
list and explaining how you are mistaken.
OK, look. I guess I need to spell it out for you.
End-user PC has virus. Virus does this:
telnet isps-smtp-server 25
HELO bogus
MAIL FROM:[EMAIL
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
No need to be condescending about it. I have no problem taking it off
list and explaining how you are mistaken.
OK, look. I guess I need to spell it out for you.
End-user PC has virus. Virus does this:
telnet isps-smtp-server 25
HELO
David F. Skoll writes:
[EMAIL PROTECTED] wrote:
i'm far from an expert but at some level i believe that you're both
right. the real question boils down (i think) to who is trying to deliver
this piece of unwanted email?
if it's a Real MTA, then kicking back a 550 will -- probably -- have the
rick pim wrote:
David F. Skoll writes:
[EMAIL PROTECTED] wrote:
i'm far from an expert but at some level i believe that you're both
right. the real question boils down (i think) to who is trying to deliver
this piece of unwanted email?
if it's a Real MTA, then kicking back a 550 will
David F. Skoll schrieb:
OK, look. I guess I need to spell it out for you.
End-user PC has virus. Virus does this:
telnet isps-smtp-server 25
In my experience that's very unusual behaviour for a virus.
The vast majority try to connect directly to the recipient's MX.
--
Tilman Schmidt
On Fri, 8 Aug 2008 11:20:54 -0400
rick pim [EMAIL PROTECTED] wrote:
David F. Skoll writes:
[EMAIL PROTECTED] wrote:
i'm far from an expert but at some level i believe that you're both
right. the real question boils down (i think) to who is trying to
deliver this piece of unwanted email?
if
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
[...]
What backscatter? If done at SMTP the only person that should be
notified is the sender.
I see. And it's impossible for a virus to forge MAIL FROM:, is it?
That is the concern of the connecting system - they will suffer any
David F. Skoll wrote:
[EMAIL PROTECTED] wrote:
No need to be condescending about it. I have no problem taking it off
list and explaining how you are mistaken.
OK, look. I guess I need to spell it out for you.
End-user PC has virus. Virus does this:
telnet isps-smtp-server 25
HELO
Gerard writes:
Employing 'greylisting' would vastly improve the chances of eliminating
the acceptance of SPAM at the MTA level.
it certainly does. unfortunately, in practice, one of the
prime advantages of greylisting -- the fact that it will never
block 'real' mail -- turns out, um, not to
On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote:
telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED]
telnet victims-server 25 ... HELO isps-server ... MAIL FROM
If victim's SMTP server fails the DATA with a 5xx code, then
backscatter goes [EMAIL PROTECTED]
it is not
Tilman Schmidt wrote:
telnet isps-smtp-server 25
In my experience that's very unusual behaviour for a virus.
The vast majority try to connect directly to the recipient's MX.
I see both. I see malware that connects directly from end-user PCs,
and more sophisticated malware that actually
On Fri, 8 Aug 2008, Charles Gregory wrote:
Well, first of all, yes it IS. It's *everyone's* problem. That forged
address could be on *your* server, and *you* get the backscatter from some
other victim system that also doesn't care what the ISP does with it...
what he said: we have two
rick pim wrote:
(that said, there's something to be said for bouncing mail: one of our
vendors is occasionally silently blocking my email to them. clearly
SOMETHING about my messages are triggering their spam filters. it sure
would be nice if i got the bounces for those)
I discard
Charles Gregory wrote:
On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote:
telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED]
telnet victims-server 25 ... HELO isps-server ... MAIL FROM
If victim's SMTP server fails the DATA with a 5xx code, then
backscatter goes [EMAIL
rick pim wrote:
On Fri, 8 Aug 2008, Charles Gregory wrote:
Well, first of all, yes it IS. It's *everyone's* problem. That forged
address could be on *your* server, and *you* get the backscatter from some
other victim system that also doesn't care what the ISP does with it...
what he said:
Charles Gregory wrote:
On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote:
telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED]
telnet victims-server 25 ... HELO isps-server ... MAIL FROM
If victim's SMTP server fails the DATA with a 5xx code, then
backscatter goes [EMAIL
[EMAIL PROTECTED] wrote:
Charles Gregory wrote:
On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote:
telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED]
telnet victims-server 25 ... HELO isps-server ... MAIL FROM
If victim's SMTP server fails the DATA with a 5xx code, then
[EMAIL PROTECTED] wrote:
I meant to imply that when the ISP does not virus filter and the
recipient silently drops the message the problem never gets resolved
because nobody is made aware of it. The ISP customer will continue
to be infected and continue to send out garbage. I suppose this
On Thu, 7 Aug 2008 10:06:09 -0400 (EDT)
jef moskot [EMAIL PROTECTED] wrote:
[snip]
Currently, we accept all infected mail, and quietly quarantine it. We
don't refuse it at SMTP connect, although I might be able to be
convinced that that's a better idea. Still, I'd like to maintain the
current
On Thu, 7 Aug 2008, Gerard wrote:
Depending on the quantity of emails your receive, you might very well
significantly reduce the load on your system by using one or perhaps a
few RBL's. There is no point, at least in opinion, of accepting mail
that is obviously SPAM.
We definitely do that
jef moskot wrote:
So, basically, all I need is a replacement for a perl script that throws a
wad of text at clamscan and then either passes it on for normal delivery
or stashes it away in a quarantine directory, with a note passed on to a
local admin address in the latter case.
I recommend
On Thu, Aug 7, 2008 at 16:40, David F. Skoll [EMAIL PROTECTED] wrote:
I recommend MIMEDefang. (Of course, I'm the author, so I would
recommend it...)
I use both amavisd-new and MIMEDefang. Of those I'd recommend MD over
amavisd-new. It's easy to customise the heck out of (I don't know perl
So, basically, all I need is a replacement for a perl script that throws a
wad of text at clamscan and then either passes it on for normal delivery
or stashes it away in a quarantine directory, with a note passed on to a
local admin address in the latter case.
I'd also recommend MIMEDefang.
On Thu, 7 Aug 2008 11:36:32 -0400 (EDT)
jef moskot [EMAIL PROTECTED] wrote:
You did not mention your MTA.
Oops, sorry. We're married to sendmail at this point.
Would you entertain a divorce?
IMHO, switching to Postfix might very well make your life easier. The
configuration is far simpler
On Thu, Aug 07, 2008 at 04:46:48PM +0100, Rob MacGregor wrote:
On Thu, Aug 7, 2008 at 16:40, David F. Skoll [EMAIL PROTECTED] wrote:
I recommend MIMEDefang. (Of course, I'm the author, so I would
recommend it...)
I use both amavisd-new and MIMEDefang. Of those I'd recommend MD over
Henrik K wrote:
I use both, but MD is IMO more of a hobbyist tool
I would not characterize it like that. MIMEDefang is a framework;
you have to implement your policy. So it's true that it doesn't ship
with many pre-canned features like Amavis does, and does require more work
on your part to
jef moskot wrote:
I didn't mean to spark a milter fight, but as the Subject line says, we're
looking for the simplest thing out there. I'm replacing a simplistic perl
script that just broke a message down, clamscanned it, and either passed
it on for delivery or quarantined and notified.
Oops!! I forgot a line; sorry!
(I'll direct followups to MIMEDefang mailing list. This is somewhat OT.)
#=
$Features{'Virus:CLAMD'} = '/full/path/to/clamd';
$ClamdSock = '/full/path/to/clamd.sock';
$Features{'Virus:CLAMAV'} = '/full/path/to/clamscan'
$AdminAddress =
On Thu, 7 Aug 2008 11:36:32 -0400 (EDT)
jef moskot [EMAIL PROTECTED] wrote:
You did not mention your MTA.
Oops, sorry. We're married to sendmail at this point.
In that case, why not just use clamav as a milter. It's been working fine for
us for the last couple of years.
Steve
jef moskot wrote:
On Thu, 7 Aug 2008, Henrik K wrote:
I use both, but MD is IMO more of a hobbyist tool...
I didn't mean to spark a milter fight, but as the Subject line says, we're
looking for the simplest thing out there. I'm replacing a simplistic perl
script that just broke a message
Gerard wrote:
On Thu, 7 Aug 2008 11:36:32 -0400 (EDT)
jef moskot [EMAIL PROTECTED] wrote:
You did not mention your MTA.
Oops, sorry. We're married to sendmail at this point.
Would you entertain a divorce?
IMHO, switching to Postfix might very well make your life easier. The
68 matches
Mail list logo
