OK, then add this functionality to the feature requests list for 2.02 RC 000001.
Thanks On Wed, Jan 20, 2010 at 12:22 AM, Thomas Eckardt/eck <[email protected]> wrote: >>but if i put the =>weight at the end of a line, a match for > that line won't block, > > No, if bombs are set to block, the weight will be used to calculate the > message- and IP-score - but the message will be blocked. > > Thomas > > > > > Von: K Post <[email protected]> > An: ASSP development mailing list <[email protected]> > Datum: 19.01.2010 21:23 > Betreff: Re: [Assp-test] Antwort: Re: Is there a way to reject mail > but not store it? > > > > Now that's just plain incredible! I didn't know that that Bomb was so > powerful. > > I have our bombs set to block. Are you saying that I could leave it > as block, but if i put the =>weight at the end of a line, a match for > that line won't block, but will score either as a percentage of the > bomb score or as a fixed score? That's terrific. > > Thanks so much for taking the time to explain this, and for working up > the examples. It'll surely help more than just measly me. > > > > On Tue, Jan 19, 2010 at 1:32 PM, Thomas Eckardt/eck > <[email protected]> wrote: >> I think you can do it with 'bombHeaderRe'. >> >> >> looking for a recipient: >> >> \nto:[^\r\n]+?the_recipie...@your_domain\.com >> >> looking for a senders domain: >> >> \nfrom:[^\r\n]+...@sender_domain\.com >> >> now combine the two regexes to block all mails from that domain to this >> recipient >> >> first case - from: before to: in the header >> >> > \nfrom:[^\r\n]...@sender_domain\.com.+?\nto:[^\r\n]+?the_recipie...@your_domain\.com >> >> >> second case - to: before from: in the header >> >> > \nto:[^\r\n]+?the_recipie...@your_domain\.com.+?\nfrom:[^\r\n]...@sender_domain\.com >> >> or all in one line: >> >> > (\nfrom:[^\r\n]...@sender_domain\.com.+?\nto:[^\r\n]+?the_recipie...@your_domain\.com|\nto:[^\r\n]+?the_recipie...@your_domain\.com.+?\nfrom:[^\r\n]...@sender_domain\.com) >> >> You can block by the regex or you can weight the regex just a tick > before >> the penalty limit - if the mail is additional scored for any other > reason >> (SPF ..) it will be blocked. >> >> all in one weighted: >> >> > ~(\nfrom:[^\r\n]...@sender_domain\.com.+?\nto:[^\r\n]+?the_recipie...@your_domain\.com|\nto:[^\r\n]+?the_recipie...@your_domain\.com.+?\nfrom:[^\r\n]...@sender_domain\.com)~=>the_weight >> >> >> to block all mails from this domain but not to this recipient: >> >> > ~(\nfrom:[^\r\n]...@sender_domain\.com).+?(?!\nto:[^\r\n]+?the_recipie...@your_domain\.com)|(?!\nto:[^\r\n]+?the_recipie...@your_domain\.com).+?\nfrom:[^\r\n]...@sender_domain\.com)~=>the_weight >> >> This examples will only work for single lines to: and from: >> >> >> Thomas >> >> >> >> Von: K Post <[email protected]> >> An: ASSP development mailing list <[email protected]> >> Datum: 19.01.2010 16:46 >> Betreff: Re: [Assp-test] Is there a way to reject mail but not >> store it? >> >> >> >> Hi all. >> >> I'm bringing this up again, as we're finding the need for this >> functionality it more and more as people get onto mailing lists that >> won't unsubscribe them, but others want to stay on the mailing list. >> >> Person A doesn't want to get any email from domain X, but it's not >> really spam mail, so we want to reject the mail like a bounce without >> storing it. >> >> The key is that Person B (and the rest of the people) do want to get >> the mail from domain x. >> >> Thanks. >> >> On Sat, Nov 14, 2009 at 8:17 AM, K Post <[email protected]> wrote: >>> Thanks Fritz. >>> >>> I know about RejectTheseLocalAddresses - I wrote it a while back :) >>> It was designed for rare cases where there's a wildcard address >>> allowed at a particular host name like *[email protected]. We had >>> some of these once upon a time. Putting an address on that list would >>> reject the specific [email protected] as if it wasn't >>> accepted by the *[email protected] match in local users. >>> >>> That won't work in this case, since the to addresses are current >>> users, we just want the sender to THINK that they sent to an invalid >>> address. >>> >>> Redlist is a good idea, but if other users want to get mail from that >>> org, it'll stop those emails from geting to the corpus too. I'd >>> prefer to avoid that if there's another way. >>> >>> So, what I'd really like to see if this is easy is a list of >>> sender=>recipient pairs (which accepts wildcards) that if it matcfhes >>> will give an Invalid User error to the sender. Similar functionality >>> to the RejectTheseLocalAddresses could be used, where it would >>> consider the local user to NOT be a local user. >>> >>> Unless there's a way of doing this now that i'm not thinking of, I'll >>> see if I can't write this too. >>> >>> I think this might be universally helpful. it would also allow a sort >>> of restraining order effect. If a person no longer wants to receive >>> mail from someone who is harraing them, we could block it this way >>> without stopping that sender from sending to other people on the >>> system. And that person would just be told that the account doesn't >>> exist, which is a good way to get them to stop emailing. Adding them >>> to red won't be a good idea since it's only emails to a specific >>> address that should be considered blocked and other mails from that >>> person should contribute to the redlist. >>> >>> Only thing that you'd need to make sure my code doesn't do is penalize >>> the sending IP or add these only simulated invalid user rejections >>> from corrupting the corpus or messing with penalties at all. This is >>> spam free mail that incapable sysadmins ./ list admins can't seem to >>> stop their servers from sending. >>> >>> >>> >>> Thanks for the additional thoughts. >>> >> >> > ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues >> through >> interactions with peers, luminaries and emerging and established >> companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Assp-test mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/assp-test >> >> >> >> >> DISCLAIMER: >> ******************************************************* >> This email and any files transmitted with it may be confidential, > legally >> privileged and protected in law and are intended solely for the use of > the >> >> individual to whom it is addressed. >> This email was multiple times scanned for viruses. There should be no >> known virus in this email! >> ******************************************************* >> >> >> > ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for > Conference >> attendees to learn about information security's most important issues > through >> interactions with peers, luminaries and emerging and established > companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Assp-test mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/assp-test >> > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > DISCLAIMER: > ******************************************************* > This email and any files transmitted with it may be confidential, legally > privileged and protected in law and are intended solely for the use of the > > individual to whom it is addressed. > This email was multiple times scanned for viruses. There should be no > known virus in this email! > ******************************************************* > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
