Re: mailx vs pine local mail scan times
Rob Fantini wrote: > I wonder if a header could be added to a mail from postfix when this > part of /etc/postfix/main.cf sees a mail as from local? > > smtpd_recipient_restrictions = > permit_mynetworks, > > The new header could be checked in procmailrc.. Hmm... I just thought of this on the fly and so there may be something I am not thinking about. But it seems easy enough to do this using postfix's PREPEND option. This requires postfix 2.1 or later. Use a PREPEND to place a new mail header of your choosing. If that header exists then run through spamassassin. If not then you know it is local and can bypass spamassassin. cat /etc/postfix/ext-access.regexp /./ PREPEND X-External-Message: yes Then in the postfix main.cf file: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, check_helo_access hash:/etc/postfix/helo-access, check_recipient_access regexp:/etc/postfix/ext-access.regexp, check_sender_access hash:/etc/postfix/client-access, ... reject_rbl_client ...your list here..., ... warn_if_reject reject_rbl_client ...your list here... Then modify the procmail rule to call spamassassin whenever this header is present in the mail. Since all external mail has this header all external mail goes through SA. :0fw * ^X-External-Message: yes | spamassassin This header would not need to be secret. If someone forged it then their mail would be checked by spamassassin. Only the absence of the header could bypass the check. External mail can't avoid it because it is placed there by your external mail relay. The danger would be that someday you modify the postfix rules and this header gets lost. At that time a lot of spam would pass through. But I am sure your users would let you know about that soon enough. Once again let me warn that I have not thought the above through in any great detail. Your suggestion just made me think of this as a way to do what you were wanting. It is not something I care about greatly because I run local mail through spamassassin and splitting out local mail is not really something I will be pursuing. But I did test the above configuration and it worked for me. Bob
Re: mailx vs pine local mail scan times
Bob Proulx wrote: If you can ensure that mail on your network is not forged We use postfix , procmail and spamassassin. I wonder if a header could be added to a mail from postfix when this part of /etc/postfix/main.cf sees a mail as from local? smtpd_recipient_restrictions = permit_mynetworks, The new header could be checked in procmailrc..
Re: mailx vs pine local mail scan times
Rob Fantini wrote: > Bob Proulx wrote: > > To improve the accuracy you need to avoid whitelists. > Should I avoid whitelists them altogether, or just for local networks > checking? The real problem is forgeries and spoofs. Anyone can put any from address they want on a mail message. Viruses especially do this routinely. Any whitelist based only on the From: address will be fooled by these. You whitelist your network and those will pass right through the checks. If you can ensure that mail on your network is not forged then whitelists for your network will be fine. But if not, then some viruses will undoubted forge your address and fool your whitelists. On my network I try hard to make sure that spoofed mail address from my own domain cannot enter my domain. But it is hard. I really can't do it. For example this message to the mailing list leaves my network, goes to the mailing list, then comes back into my network. The message contains my From: address. Any whitelist I would have on my domain would be fooled if that were spoofed. Because of this problem I don't like any algorithm that by design trusts the user. "Who goes there, friend or foo?" "Friend!" "Well, okay fine, you may pass." Therefore I don't like simple "From: name" whitelists. They have that fundamental flaw. I always try to avoid them. So then you ask what is the alternative? In spamassassin it follows the chain of hosts through the trusted_networks variable backtracking through the Received: headers. When it finds the point that mail enterred your network it can use that foreign machine's IP address and perform network checks. If the mail never left the network it sets ALL_TRUSTED which is good for negative points pushing the message to the non-spam classification. It would be great to have that capability available as a standalone script outside of the full spamassassin check. It was a check like that I was suggesting to really know if the mail came from your network. But as far as I know it is not available outside of spamassassin at this time. If someone had the inclination they could write that check in a standalone form. Bob
Re: mailx vs pine local mail scan times
Bob Proulx wrote: > How are you calling spamassassin? Are you calling it through procmail? Yes If so then you can use procmail to avoid calling spamassasin in those cases. The easiest thing would be to avoid processing through spamassassin if the from address were on your network. :0fw * !^From: .*@([^.]+\.)?example.com | spamassassin Thank you, that is just what I was looking for. To improve the accuracy you need to avoid whitelists. Should I avoid whitelists them altogether, or just for local networks checking?
Re: mailx vs pine local mail scan times
Rob Fantini wrote: > Is there a way to disable spamassassin from processing mail sent to > our local network from our local network? How are you calling spamassassin? Are you calling it through procmail? If so then you can use procmail to avoid calling spamassasin in those cases. The easiest thing would be to avoid processing through spamassassin if the from address were on your network. :0fw * !^From: .*@([^.]+\.)?example.com | spamassassin This runs the risk that you will see spam from your forged addresses. Those are called joe-jobs. But if that does not bother you too much then this works. To improve the accuracy you need to avoid whitelists. If you had a mail filter program that checked that the message originated on your network then you could use that as part of the procmail check instead of just the From: address. I don't happen to have one handy to post. But if someone else did I would be interested in something like that myself. Bob
Re: mailx vs pine local mail scan times
>At very least, try this test with 3 consecutive mails per client to get >some feel of varriance in network lookup times. I ran the tests you suggested and sure enough it averages about the same for pine and mailx mails to be processed. Is there a way to disable spamassassin from processing mail sent to our local network from our local network?
Re: mailx vs pine local mail scan times
At 12:36 PM 3/5/2005, Rob Fantini wrote: Hello, - mailx [command line] mail is processed 5x faster than mail sent using pine. Your difference in time is 1.1 second vs 5.8 seconds. Is that always consistent over a large set of emails? I can see from your results you've got network checks enabled, including razor. That's going to introduce considerable variability between scan times for a single message. Sometimes razor takes a half second to respond, other times it takes several seconds. With network checks enabled it's pretty difficult to compare scan times unless you have a huge sample set (>20,000 messages) to average together. Also, this particular test is slightly questionable because the two emails are back-to-back, and the first one is slower. The second scan is going to benefit from the DNS resolver caching the DNS query results from the first message. At very least, try this test with 3 consecutive mails per client to get some feel of varriance in network lookup times.