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 certa
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
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 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 t
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 mai
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
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 recipie
> -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 tim
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 hi
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 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, b
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 compa
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
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 mone
--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
--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 gr
Hi Parveen,
>Steven,
>
>I have a secured environment which governed by HIPAA regulatory, so I
>can't keep open everything.
>
>Thanks,
>Parveen
The only port you need to get an up to date clamav database is the
outgoing HTTP port (TCP:80) [ and DNS so you can get an upto date IP for
the server y
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 de
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 feelin
[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
[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 co
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 [
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"...
>
> wh
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 [
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 vi
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 ac
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 b
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]
> i
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
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-serv
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
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 emai
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
Phoen
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
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
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-serv
[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 PROTE
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 SM
[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 w
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/cli
[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
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?
No, is is trivial for anyone to forge "mail from" headers but that
bject: 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 t
[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
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
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
[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/SpamAs
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 db.us.cl
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 y
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
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
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 recorde
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
[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 bl
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 bei
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 clien
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
jef moskot wrote:
>
> Any advice would be welcome, including "STFU and RTFM", as long as you can
> point me to a decent manual. Thanks!
I've been using J-Chkmail for years and I love it because there is no
Perl (I really like Perl but I hate CPAN - two or more trips to CPAN to
get something w
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.
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 mes
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
pg
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 = '
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.
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 down, clamscanned it, an
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 c
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 M
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 sim
> 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 MIMEDefan
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 pe
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 recommen
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
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
>cur
72 matches
Mail list logo
