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
