-------- Original-Nachricht --------
> Datum: Tue, 28 Jul 2009 23:54:12 +0100
> Von: Hugo Monteiro <[email protected]>
> An: [email protected]
> Betreff: Re: [Dspam-user] Dealing SPAM

> Steve wrote:
> > -------- Original-Nachricht --------
> >   
> >> Datum: Tue, 28 Jul 2009 22:40:32 +0100
> >> Von: Hugo Monteiro <[email protected]>
> >> An: [email protected]
> >> Betreff: Re: [Dspam-user] Dealing SPAM
> >>     
> >
> >   
> >> Steve wrote:
> >>     
> >>> -------- Original-Nachricht --------
> >>>   
> >>>       
> >>>> Datum: Tue, 28 Jul 2009 15:31:09 -0500
> >>>> Von: Troy Ayers <[email protected]>
> >>>> An: 
> >>>> CC: [email protected]
> >>>> Betreff: Re: [Dspam-user] Dealing SPAM
> >>>>     
> >>>>         
> >>>   
> >>>       
> >>>> Julien Valroff wrote:
> >>>>     
> >>>>         
> >>>>> Le mardi 28 juillet 2009 à 19:52 +0200, Steve a écrit :
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> -------- Original-Nachricht --------
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>>>> Datum: Tue, 28 Jul 2009 12:49:37 -0400
> >>>>>>> Von: Roman Gelfand <[email protected]>
> >>>>>>> An: [email protected]
> >>>>>>> Betreff: [Dspam-user] Dealing SPAM
> >>>>>>>       
> >>>>>>> I am not sure if I understood this correctly... Upon determination
> >>>>>>>           
> >>>>>>>               
> >>>> that
> >>>>     
> >>>>         
> >>>>>>> email is spam, the mail spam email could be either forwarded with
> a
> >>>>>>>           
> >>>>>>>               
> >>>> tag in
> >>>>     
> >>>>         
> >>>>>>> header or quarantined.  If this is true, is there a way to tell
> >>>>>>>               
> >> dspam
> >>     
> >>>>>>>           
> >>>>>>>               
> >>>> to
> >>>>     
> >>>>         
> >>>>>>> drop conneciton, without storing email anywhere, upon
> determination
> >>>>>>>           
> >>>>>>>               
> >>>> that
> >>>>     
> >>>>         
> >>>>>>> email is span?
> >>>>>>>
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>> No. There is no such thing. I know that functionality been
> requested
> >>>>>>             
> >> in
> >>     
> >>>>>>         
> >>>>>>             
> >>>> the past. Something like:
> >>>>     
> >>>>         
> >>>>>> If result = spam and confidence factor >= 0.50 and probability >=
> >>>>>>             
> >> 0.75
> >>     
> >>>>>>         
> >>>>>>             
> >>>> then log and drop message
> >>>>     
> >>>>         
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> Wouldn't this be MDA's responsibility?
> >>>>>
> >>>>> This feature would be interesting if it could (also) be set on a
> >>>>> per-user/group basis, with the possibility to configure this from
> the
> >>>>> webui.
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> What if an email is addressed to multiple recipients?  And if some of
> >>>> the users' dspam training says the message is spam, some say it's
> not, 
> >>>> or some users are not opted-in or are opted-out, who wins?
> >>>>
> >>>>     
> >>>>         
> >>> The current user wins. DSPAM only knows about one user and that is the
> >>>       
> >> one currently being processed by DSPAM. So if DSPAM drops that mail
> then
> >> only for that user. Other users have their own instance of DSPAM
> running and
> >> doing the work for them.
> >>     
> >>>   
> >>>       
> >> That is almost absolutely true =). It surely is true for DSPAM
> execution 
> >> at the MDA/LDA or whenever DSPAM is called after multiplexing the 
> >> message, which will eventually happen if it has multiple recipients.
> >>
> >> BUT there are some cases when that is not the case. If DSPAM is being 
> >> used to check messages at SMTP level, so you can reject the message
> with 
> >> a 4XX or 5XX SMTP error code for instance (simscan or qmail-scanner
> come 
> >> to my mind), AND the sending SMTP server has chosen to send the message
> >> with multiple recipients (some do that, some don't), then you have a 
> >> problem.
> >>
> >>     
> > But DSPAM is anyway multiple user unaware (at once). If now someone
> chooses to use DSPAM as a pure content filter and MISSUSING (in therms of not
> using its unique per user feature) then you can't blame DSPAM for it's
> result. I mean assuming you would do the above then you need somehow to tell
> DSPAM under what user to process the message (let's say that user would be
> "hugo") then how can you blame DSPAM for it's result? You said it should be
> processed under user "hugo" and assuming we would have that dropping message
> functionality then DSPAM would process the message and would say: all
> tokens and data for user "hugo" do compute the message in question to be SPAM
> and user "hugo" has told me (via preference extension or other mechanism) to
> drop that mail and I (DSPAM) am exactly going to do that. DSPAM is not the
> one to blame here. It's the person/sysadmin who has setup DSPAM to work
> that way.
> >
> >
> >   
> >> In my very personal opinion, if you want an hassle free setup, don't
> use 
> >> DSPAM/SpamAssassin to block messages at SMTP level. There are better 
> >> ways to stop Spam at that level, and leave DSPAM to process the
> messages 
> >> that do get through those earlier barriers. That approach will also
> save 
> >> you lot's of CPU cycles and DSPAM backend storage.
> >>
> >>     
> > Don't say that to me. I do that.
> 
> I was actually advising Roman ;)
> 
> >  I block over 80% and some days around 95% of all inbound mail before it
> reaches DSPAM. My users would freak out if I would let that stuff pass up
> to DSPAM. Not that DSPAM would not filter it. It would. Even with a high
> accuracy but who is going to check all that tagging? Years ago when I on one
> day got around 65'000 SPAM mails and just 7 HAM messages I decided to stop
> trusting ISP's and start to filter my own mail (it took me the whole day to
> unspam my inbox). I did at that time already filtered mail and blocked
> (for others) but not for my own account (I only tagged mail for my account).
> And ever since that time I look to block as much as possible before the mail
> enters the queue. I know, I know. Now all of you will jump up and down and
> tell me that this is insane to block so much and that I probably have a
> high FN/FP rate. But I don't. Believe it or not but I do have customers
> trading (for example) steel. The steel price is so volatile that every minute
> the price can change. And beside that every mail not reaching them can cost
> them a lot of money. And guess what? Very, very, very rarely do I block some
> legitimate sender. And even if I do, the customer has the possibility to
> whitelist a sender. Or for example I do have a customer in the
> transportation business. I can bet my last dollar that sure one of their 
> contacts is
> somewhere on a blocking list. Most of those transport agents from Russia
> and/or Asia are at least in one BL, RBL, RHBL or whatever other blocking list.
> And even there I rarely have legitimate senders blocked. It's all a question
> how you setup the mailflow. A lot of sysadmins think that technology is
> the key for good mailflow and that the tools they use is the solution to the
> SPAM problem. But it is not! Good mailflow is a constant process and not
> just a bunch of tools you setup and forget about it. You need constantly to
> look after it (I mean the mailflow). It's like a baby that needs attention
> as much as it can get it.
> >
> >
> >   
> 
> Indeed. I couldn't agree more with all that you said.
> 
> It's too bad that many decision makers think that it's just about 
> spending top dollar in some appliance and forget about the subject.
> 
It's not that simple. It's not just them. We (the community and the industry) 
are part of the problem as well.


> R's,
> 
> Hugo.
> 
// Steve

> -- 
> ci.fct.unl.pt:~# cat .signature
> 
> Hugo Monteiro
> Email  : [email protected]
> Telefone : +351 212948300 Ext.15307
> Web      : http://hmonteiro.net
> 
> Centro de Informática
> Faculdade de Ciências e Tecnologia da
>                  Universidade Nova de Lisboa
> Quinta da Torre   2829-516 Caparica   Portugal
> Telefone: +351 212948596   Fax: +351 212948548
> www.ci.fct.unl.pt           [email protected]
> 
> ci.fct.unl.pt:~# _
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Dspam-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspam-user

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user

Reply via email to