> > There are various "band-aid" approaches, like running the outbound > > mail through spamassassin and HOLDing the "spammy" mail, however > > this may or may not catch what you want, since even SpamAssassin > > has no idea if the user actually wanted the mail or not. > > Yes, we already do that, and more. In fact, I'm not that worried > because of the contents of the emails, I'm mostly worried because > sending emails to more than 500 people in the recipient list is not > very polite, and can trigger undesired actions. People sometimes have > poorly designed web pages with a not-too good php emailing code. > > For instance. I'd like to find a way (maybe through some header checks > in outgoing email) so if it detects a large amount of recipients it > triggers actions such as: > > 1.- Adding the 'Precedence: bulk' header field > 2.- Clean the message for non-valid characters > 3.- If a non-valid sender address is detected, block the sending (for > instance, someone may send bulk-email with a From: > [email protected] (the apache user) > 4.- If the recipient list has invalid recipient domains block the > whole sending. > 5.- Of course, any modification of the email should be done before > doing the dk/dkim signing, which we already do. > > Can this be (totally or partially) done?
The question you are asking is whether it is possible to implement a flawed security model with toolset X, where toolset X includes Postfix along with assorted deployment recipes and milter applications. The long and the short of it is that there absolutely are tools that will allow you to do that, but there isn't support for that approach to the problem because of the fundamental flaws. You've described an "allow, then deny" scenario for filtering outbound mail from untrusted users on your network. The reality behind this security model is that the untrusted users will constantly be inventing new ways to abuse your resources, including your IP address space. The alternative is the "deny, then allow" model. Here you stop all traffic and make sure it conforms to specific guidelines before you relay it outside the network. The difference is, instead of having a list of *don't* rules, you have a list of *do* rules. It's inconvenient, intrusive and your definitions might still permit undesirable content. The simple solution is to separate your mail streams. Content you control should not be going out over the same IP addresses that send content you do not control. Use a different, preferably non-adjacent, block if possible. You should probably do that to your marketing department, too. :-) You still need to work to protect your customers from eachother. Ideally, each customer should be individually accountable for their sender reputation. If your business model doesn't support that then you could give each customer a different internal interface and establish your own reputation metrics as a basis for routing their mail to your Internet-facing mail servers, in effect creating a risk pool for mail senders. It's still expensive and sub-optimal, but it's not entirely doomed. More importantly, it's a path toward the re-evaluation of the business model. Chris Babcock
signature.asc
Description: PGP signature
