On Mon, 12 Dec 2005, Stephen Sprunk wrote:
> > It still doesn't make sense to send notification in any form other
> > than a "5xx stuff your malware..." response.
> The sending MTA, provided it's not the malware or spam software itself, will
> simply read the in-band 5xx and send a DSN to the fo
Thus spake "Per Heldal" <[EMAIL PROTECTED]>
On Mon, 12 Dec 2005 14:18:07 +, [EMAIL PROTECTED] said:
[snip]
This whole discussion centered around the fact that
innocent 3rd parties with no ability to act, were being
sent large volumes of notifications. Once you remove the
innocent 3rd party
On Mon, 12 Dec 2005 14:18:07 +, [EMAIL PROTECTED] said:
[snip]
> This whole discussion centered around the fact that
> innocent 3rd parties with no ability to act, were being
> sent large volumes of notifications. Once you remove the
> innocent 3rd party from the equation, the shape of the
>
On Mon, 12 Dec 2005, [EMAIL PROTECTED] wrote:
> > No information you can collect from the SMTP-session or elsewhere can
> > ever compete with the accuracy in notification gained if you reject the
> > message in-line and leave the responsibility for sender-notification
> > with the sending MTA.
>
> No information you can collect from the SMTP-session or elsewhere can
> ever compete with the accuracy in notification gained if you reject the
> message in-line and leave the responsibility for sender-notification
> with the sending MTA.
On the other hand, sending the DSNs back to the sending
On Mon, 12 Dec 2005, [EMAIL PROTECTED] wrote:
> > > This assumes all messages are rejected within the SMTP session.
> >
> > Yes, exactly and the point several of us have been making is that
> > this is (a) easy (well, provided you're using a quality MTA; if not,
> > then switch to one) (b) runnin
On Mon, 12 Dec 2005 11:08:14 +, [EMAIL PROTECTED] said:
[snip]
>
> Not quite the only way. If a postprocessing step is needed,
> it is trivial for the SMTP server to record any return path info
> that it knows in order for the post-processor to be able to
> send DSN's as accurately as the SM
> > This assumes all messages are rejected within the SMTP session.
>
> Yes, exactly and the point several of us have been making is that
> this is (a) easy (well, provided you're using a quality MTA; if not,
> then switch to one) (b) running a sane mail system (c) fast
> (d) resource-friendly an
On Wed, Dec 07, 2005 at 02:15:00PM -0800, Douglas Otis wrote:
> >When auth fails, one knows *right then* c/o an SMTP reject. No bounce
> >is necessary.
>
> This assumes all messages are rejected within the SMTP session.
Yes, exactly and the point several of us have been making is that
this is (
On Thursday 08 Dec 2005 18:08, Douglas Otis wrote:
>
> When accepting messages from anonymous sources, seldom does one know
> the source.
On the contrary, short of the tricks played on AOL to defeat their original
antispam system, TCP means you always know the source.
We manage to filter out ~9
On Dec 8, 2005, at 2:18 AM, [EMAIL PROTECTED] wrote:
It seems reasonable to design a mail system so that notifications
are sent back to the originator of the message when there is a
problem somewhere along the delivery chain.
Agreed. The alternative would be more like instant messaging.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Thu 08 Dec 2005, 12:11 CET]:
The RFC process itself is broken when clueless vendors treat RFCs as
inviolable specs and implement according to the RFC even when they find
flaws in it. If they want to remain true to the RFC process, they should
not implem
> Perhaps DSNs should be sent to the original recipient, not the purported
> sender. RFC-compliant? No.
The RFC process itself is broken when clueless vendors
treat RFCs as inviolable specs and implement according to
the RFC even when they find flaws in it. If they want to
remain true to the
> Some may see it as a
> violation of RFC to not return a DSN on failed delivery.
It seems reasonable to design a mail system so that
notifications are sent back to the originator of the
message when there is a problem somewhere along
the delivery chain.
> Others, like myself
> see the need t
DO> Date: Wed, 7 Dec 2005 17:02:51 -0800
DO> From: Douglas Otis
DO> > H. BATV-triggered bounces. Virus triggers forged bounce which in
DO> > turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth
DO> > growth of the '90s will continue. ;-)
DO>
DO> BATV should not trigger any
On Dec 7, 2005, at 4:06 PM, Edward B. Dreger wrote:
H. BATV-triggered bounces. Virus triggers forged bounce which in
turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth
growth of the '90s will continue. ;-)
BATV should not trigger any bounce as this only changes the l
DO> Date: Wed, 7 Dec 2005 14:15:00 -0800
DO> From: Douglas Otis
DO> > Perhaps DSNs should be sent to the original recipient, not the purported
DO> > sender. RFC-compliant? No. Ridiculous? Less so than pestering a
DO> > random third party. Let the intended recipient communicate OOB or
DO> > m
On Dec 7, 2005, at 1:35 PM, Edward B. Dreger wrote:
DO> Not all email is rejected within the SMTP session. You are
changing
DO> requirements for recipients that scan incoming messages for
malware. Fault
DO> them for returning content or not including a null bounce-
address. No one
DO>
DO> Date: Tue, 6 Dec 2005 16:26:16 -0800
DO> From: Douglas Otis
DO> I know of no cases where a malware related DSN would be generated by our
Good.
DO> products, nevertheless, DSNs are not Unsolicited Bulk Email.
Huh? I get NDRs for mail that "I" sent. I do not want those NDRs. I
did not r
On Tue, 6 Dec 2005, Douglas Otis wrote:
> > Not my problem. I don't need or want, and should not be hammered with,
> > virus "warnings" sent to forged addresses -- ever. They are unsolicited (I
> > didn't request it, and definitely don't want it), bulk (automated upon
> > receipt of viruses by
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: "Todd Vierling" <[EMAIL PROTECTED]>
Cc: "Steven M. Bellovin" <[EMAIL PROTECTED]>; "Church, Chuck"
<[EMAIL PROTECTED]>;
Sent: Tuesday, December 06, 200
On Tue, 6 Dec 2005, Douglas Otis wrote:
> > Not my problem. I don't need or want, and should not be hammered
> > with, virus "warnings" sent to forged addresses -- ever. They are
> > unsolicited (I didn't request it, and definitely don't want it),
> > bulk (automated upon receipt of virus
* Steven M. Bellovin:
> A-V companies are in the business of analyzing viruses.
Many offer analysis services, but this is done upon special request,
and only if you pay extra.
> They should *know* how a particular virus behaves.
You don't need to know what the virus does in order to detect it
On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote:
On Tue, 6 Dec 2005, Douglas Otis wrote:
Holding at the data phase does usually avoid the need for a DSN,
but this
technique may require some added (less than elegant) operations
depending upon
where the scan engine exists within the email
On Tue, 6 Dec 2005, Douglas Otis wrote:
> > > A less than elegant solution as an alternative to deleting the message, is
> > > to hold the data phase pending the scan.
> >
> > Contrary to your vision of this option, it is not only elegant; it happens
> > to be the *correct* thing to do.
>
> Holdi
On Dec 6, 2005, at 8:19 AM, Todd Vierling wrote:
On Mon, 5 Dec 2005, Douglas Otis wrote:
A less than elegant solution as an alternative to deleting the
message, is
to hold the data phase pending the scan.
Contrary to your vision of this option, it is not only elegant; it
happens
to b
On Mon, 5 Dec 2005, Douglas Otis wrote:
> A less than elegant solution as an alternative to deleting the message, is
> to hold the data phase pending the scan.
Contrary to your vision of this option, it is not only elegant; it happens
to be the *correct* thing to do.
Dropping the message on the
On Mon, 05 Dec 2005 17:38:00 PST, Douglas Otis said:
> pending the scan. Another solution would be not returning message
> content within a DSN. This would mitigate the distribution of
> viruses, as well as forged bounce-addresses sent to a backup MTAs as
> a method for bypassing black-hol
On Dec 4, 2005, at 8:04 PM, Steven M. Bellovin wrote:
"Church, Chuck" writes:
The ideal solution would be for the scanning software to send a
warning only if the virus detected is known to use real addresses,
otherwise it won't warn.
A-V companies are in the business of analyzing viru
On Sun, Dec 04, 2005 at 09:27:58PM -0600, Church, Chuck wrote:
> What about all the viruses out there that don't forge addresses?
Three responses.
First, these are pretty much a minority nowadays: so unless someone
wants to code AV responses on a case-by-case basis, the best default
is "don't re
On Sun, Dec 04, 2005 at 03:18:29PM -0800, Steve Sobol wrote:
> Blocking based on rDNS simply because it implies that a certain piece of
> equipment is at that address is... not advisable.
Agreed. Those blocks aren't in place because there's a certain piece
of equipment at those addresses (hostn
own it (and
dispose of it).
Chuck
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Todd Vierling
Sent: Sunday, December 04, 2005 4:53 PM
To: W.D.McKinney
Cc: nanog@merit.edu
Subject: RE: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, 4
> From [EMAIL PROTECTED] Sun Dec 4 22:34:54 2005
> Date: Mon, 05 Dec 2005 04:30:26 + (GMT)
> From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
> Subject: Re: Clueless anti-virus products/vendors (was Re: Sober)
> To: "Steven M. Bellovin" <[EMA
On Sun, 4 Dec 2005, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, "Chur
> ch, Chuck" writes:
> >
> >What about all the viruses out there that don't forge addresses?
> >Sending a warning message makes sense for these. Unless someone has
>
> A-V companies are in the business of analy
On Sun, 4 Dec 2005, Church, Chuck wrote:
> What about all the viruses out there that don't forge addresses?
Not that there are nearly as many -- the main scourge is sender-forging
worms by a better than 90%/10% margin -- but I very specifically mentioned:
> > > (Virus "warnings" to forged addre
An even more cynical way would be to say that most antivirus
companies aren't in the business of analyzing viruses - they are in
the business of selling antivirus software.
I believe that is the fundamental problem.
Jamie
--
Jamie C. Pole
[EMAIL PROTECTED]
http://www.jcpa.com
InfoSec /
SMB> Date: Sun, 04 Dec 2005 23:04:52 -0500
SMB> From: Steven M. Bellovin
SMB> A-V companies are in the business of analyzing viruses. They should
SMB> *know* how a particular virus behaves.
The cynical would say they _do_ know, and "accidental" backscatter is a
way to advertise their products
In message <[EMAIL PROTECTED]>, "Chur
ch, Chuck" writes:
>
>What about all the viruses out there that don't forge addresses?
>Sending a warning message makes sense for these. Unless someone has
>done the research to determine the majority of viruses forge addresses,
>you really can't complain abo
On Sunday 04 December 2005 21:27, Church, Chuck wrote:
> What about all the viruses out there that don't forge addresses?
> Sending a warning message makes sense for these. Unless someone has
> done the research to determine the majority of viruses forge addresses,
> you really can't complain abo
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Todd Vierling
Sent: Sunday, December 04, 2005 4:53 PM
To: W.D.McKinney
Cc: nanog@merit.edu
Subject: RE: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, 4 Dec 2005, W.D.McKinney wrote:
(Virus "warnings" to forged
>>What about all the viruses out there that don't forge addresses?
What virus in the past 2 years doesn't forge the from address?
George Roettger
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Todd Vierling
Sent: Sunday, December 04, 2005 4:53 PM
To: W.D.McKinney
Cc: nanog@merit.edu
Subject: RE: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, 4 Dec 2005, W.D.McKinney wrote:
> > (Vir
> From [EMAIL PROTECTED] Sun Dec 4 17:19:43 2005
> Date: Sun, 04 Dec 2005 15:18:29 -0800
> From: Steve Sobol <[EMAIL PROTECTED]>
> To: Rich Kulawiec <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Clueless anti-virus products/vendors (was Re: So
Rich Kulawiec wrote:
And thus we now have blacklist entries such as:
barracuda1.aus.texas.net
barracuda.yale-wrexham.ac.uk
barracuda.morro-bay.ca.us
barracuda.ci.mtnview.ca.us
barracuda.elbert.k12.ga.us
barracuda.fort-dodge.k12.ia.us
barr
On Sun, 4 Dec 2005, W.D.McKinney wrote:
> > (Virus "warnings" to forged addresses are UBE, plain and simple.)
>
> Since when? I disagree.
UBE = "unsolicited bulk e-mail".
Which of those three words do[es] not apply to virus "warning" backscatter
to forged envelope/From: addresses? Think carefu
On Sun, Dec 04, 2005 at 09:58:20AM -0500, Todd Vierling wrote:
> If it is on by default, it is a bug, and not operator error.
(In the case of the Barracuda) there are at least two such switches:
one for spam, one for viruses. Note that when both are set to "off" that
the box still occasionally e
On Dec 4, 2005, at 2:06 PM, W.D.McKinney wrote:
Can people building virus scanning devices PLEASE GET A %^&*^ CLUE?
This means you, Barricuda Networks, more than anyone else, but we
also see this annoyance from Symantec devices, and from some AOL
systems as well.
It's a simple switch in the
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Todd Vierling
> Sent: Sunday, December 04, 2005 5:58 AM
> To: W.D.McKinney
> Cc: [EMAIL PROTECTED]
> Subject: Re: Clueless anti-virus products/vendors (was Re: Sober)
>
On Sat, 3 Dec 2005, W.D.McKinney wrote:
> >Can people building virus scanning devices PLEASE GET A %^&*^ CLUE?
> >This means you, Barricuda Networks, more than anyone else, but we
> >also see this annoyance from Symantec devices, and from some AOL
> >systems as well.
>
> It's a simple switch in t
On 12/3/05, Daniel Senie <[EMAIL PROTECTED]> wrote:
> Can people building virus scanning devices PLEASE GET A %^&*^ CLUE?
> This means you, Barricuda Networks, more than anyone else, but we
> also see this annoyance from Symantec devices, and from some AOL
> systems as well.
The worst offenders th
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Richard Cox
> Sent: Friday, December 02, 2005 4:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Clueless anti-virus products/vendors (was Re: Sober)
>
>
> On Sat,
On Sat, 03 Dec 2005 00:45:05 +
"W.D.McKinney" <[EMAIL PROTECTED]> wrote:
> It's a simple switch in the GUI of Barracuda Networks to turn of
> this annoyance. More operator error than Barracuda's fault, IMHO.
Not if a software upgrade from Barracuda can cause the current
configuration to be si
>-Original Message-
>From: Daniel Senie [mailto:[EMAIL PROTECTED]
>Sent: Friday, December 2, 2005 11:27 AM
>To: [EMAIL PROTECTED]
>Subject: Clueless anti-virus products/vendors (was Re: Sober)
>
>
>At 03:12 PM 12/2/2005, Michael Loftis wrote:
>
>
>
>>--On December 2, 2005 2:02:15 PM -0600
On Friday 02 December 2005 14:27, Daniel Senie wrote:
> Oh, and please delete the infected file rather than sending that along too.
Here, Here Roughly 50 percent of the sober messages I have been getting
hammered with are the basic "sorry we could not deliver your virus message,
so here it
54 matches
Mail list logo
