Strategies to Prevent Abuse in Bulk-Mailing?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Strategies to Prevent Abuse in Bulk-Mailing?

Ignacio Garcia-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys. I've been googling around looking for info on this without much
sucess. Here we are: Some of my customers insist on sending bulk-email
from their web php sites (you know, bulletins and such). My worst
nightmare would be having our servers listed in any RBL list because of
this. How do you guys deal with custommers sending bulk-mail? Are there
any rules in postfix to prevent it, maybe even delaying them in the queue?

Thanks,

Ignacio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpU0vsACgkQoYMx3fsuWupQ4ACcD4VK6anNBYOYX5DWl0KuceWA
Px0An1YNSykuBHExZqroKI+kPyfHucV4
=OI9W
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Strategies to Prevent Abuse in Bulk-Mailing?

Terry Carmen
> Hi guys. I've been googling around looking for info on this without much
> sucess. Here we are: Some of my customers insist on sending bulk-email
> from their web php sites (you know, bulletins and such). My worst
> nightmare would be having our servers listed in any RBL list because of
> this. How do you guys deal with custommers sending bulk-mail? Are there
> any rules in postfix to prevent it, maybe even delaying them in the queue?

Unfortunately, this is a human problem, not a technology problem.

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.

I worked for a very large ISP a number of years ago, and they handled the
problem with a good legal team and really good contract that specified huge
financial penalties for spamming. This actually worked very well, since the
customers would either refrain from spamming, or would be terminated, forfeit
their hardware and be sued.

You might want to do the same, as well as suggest that your customers use an
outside mailing-list provider.

Terry

--
CNY Support, LLC
Web. Database. Business
http://www.cnysupport.com



Reply | Threaded
Open this post in threaded view
|

Re: Strategies to Prevent Abuse in Bulk-Mailing?

Leonardo Rodrigues Magalhães
Terry Carmen escreveu:
>
> 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.
>
>  

    another approach is to setup some quotas for outgoing messages. Try
to setup some quota based on number of messages sent in a specific
period of time.

    This will certainly not avoid the 'small' spamming sending, but
could potentially break the big ones.

    policyd, for example, can deploy quotas based on SASL authenticated
username, email addresses, quota based on number of messages as well as
traffic of those, and other things.

    again, it will not fix the problem, but maybe avoid it to became a
HUGE problem.

--


        Atenciosamente / Sincerily,
        Leonardo Rodrigues
        Solutti Tecnologia
        http://www.solutti.com.br

        Minha armadilha de SPAM, NÃO mandem email
        [hidden email]
        My SPAMTRAP, do not email it





smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Strategies to Prevent Abuse in Bulk-Mailing?

Ignacio Garcia-4
In reply to this post by Terry Carmen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Terry Carmen escribió:

>> Hi guys. I've been googling around looking for info on this without much
>> sucess. Here we are: Some of my customers insist on sending bulk-email
>> from their web php sites (you know, bulletins and such). My worst
>> nightmare would be having our servers listed in any RBL list because of
>> this. How do you guys deal with custommers sending bulk-mail? Are there
>> any rules in postfix to prevent it, maybe even delaying them in the queue?
>
> Unfortunately, this is a human problem, not a technology problem.
>
> 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: [hidden email]
(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?

Thanks,

Ignacio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpU6hoACgkQoYMx3fsuWupSygCgraZ98tZkNMKLJ53Je0Qt1nNi
5HkAoLx6+xkp8K4nKRCaVadauqV7JIFl
=1fQB
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

OT: Re: Strategies to Prevent Abuse in Bulk-Mailing?

Terry Carmen
>>> Hi guys. I've been googling around looking for info on this without much
>>> sucess. Here we are: Some of my customers insist on sending bulk-email
>>> from their web php sites (you know, bulletins and such). My worst
>>> nightmare would be having our servers listed in any RBL list because of
>>> this. How do you guys deal with custommers sending bulk-mail? Are there
>>> any rules in postfix to prevent it, maybe even delaying them in the queue?
>>
>> Unfortunately, this is a human problem, not a technology problem.
>>
>> 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: [hidden email]
> (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?

1, 2 & 3 are possible but probably not helpful.

4 is possible but not useful for fixing your problem (if the recipient domain
is invalid, the mail won't go out anyway).

I'm not sure if #5 would be good or bad, but it won't stop anybody from
sending spam.

It takes very little spam to get blacklisted (sometimes as little as a single
message to the right spamtrap). There is no technology that I'm aware of that
will stop this.

If you don't want your server to be blacklisted, you need to make sure the
users don't send spam, or you need to tell them they have to contract with an
external mail provider.

Terry





Reply | Threaded
Open this post in threaded view
|

OT - Re: Strategies to Prevent Abuse in Bulk-Mailing?

Chris Babcock-7
In reply to this post by Ignacio Garcia-4

> > 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:
> [hidden email] (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 (500 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Strategies to Prevent Abuse in Bulk-Mailing?

Barney Desmond
In reply to this post by Ignacio Garcia-4
2009/7/9 Ignacio Garcia <[hidden email]>:
> can trigger undesired actions. People sometimes have poorly designed web
> pages with a not-too good php emailing code.

Practically guaranteed :)

> 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:

This check won't be possible in Postfix, but I'm sure there's a milter
for the job.

> 3.- If a non-valid sender address is detected, block the sending (for
> instance,  someone may send bulk-email with a From: [hidden email]
> (the apache user)

On a tangent, this one is hard. Local submission ("the sendmail
binary") isn't allowed/expected to fail, which is how a lot of web
pages/apps will send their mail. Because you don't get the opportunity
to reject as part of an SMTP transaction, you need to jump through
some hoops to prevent an undesirable From address going out.
Reply | Threaded
Open this post in threaded view
|

Re: Strategies to Prevent Abuse in Bulk-Mailing?

Ramprasad-5
In reply to this post by Ignacio Garcia-4
On Wed, 2009-07-08 at 19:10 +0200, Ignacio Garcia wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi guys. I've been googling around looking for info on this without much
> sucess. Here we are: Some of my customers insist on sending bulk-email
> from their web php sites (you know, bulletins and such). My worst
> nightmare would be having our servers listed in any RBL list because of
> this. How do you guys deal with custommers sending bulk-mail? Are there
> any rules in postfix to prevent it, maybe even delaying them in the queue?
>
> Thanks,
>
This may be OT here

Outgoing spam scanning is a very good option. Unlike incoming , here you
dont have to catch all the spam. Just one spam caught , and you know who
is the culprit.

What I do is to reduce the scanning I only scan messages sent to
russia,china, taiwan etc. (based on domain tlds). Since legitimate
traffic from my servers to these are much smaller they usually catch a
lot of spam, with very little penalty of scanning. This works for me
because most outbreaks are due to weak passwords or some virus. Ofcourse
YMMV

One more thing you must do is monitor abuse complaints, Create Feedback
loops with aol, yahoo etc. (Unfortunately gmail doesnt seem to have
one)

Anyway you really dont have to worry too much. No one blacklists you
because of just one or two spams inadvertently relayed thru your
network.
You just have to bother about customers who deliberately spam, we have
had very bad experiences and since then we have been insisting on
getting a bullet-proof TOS signed.






> Ignacio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpU0vsACgkQoYMx3fsuWupQ4ACcD4VK6anNBYOYX5DWl0KuceWA
> Px0An1YNSykuBHExZqroKI+kPyfHucV4
> =OI9W
> -----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Strategies to Prevent Abuse in Bulk-Mailing?

shdjsahwkjq ehwq kehwkq h
On Jul 8, 2009, at 10:00 PM, ram wrote:

> On Wed, 2009-07-08 at 19:10 +0200, Ignacio Garcia wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi guys. I've been googling around looking for info on this without  
>> much
>> sucess. Here we are: Some of my customers insist on sending bulk-
>> email
>> from their web php sites (you know, bulletins and such). My worst
>> nightmare would be having our servers listed in any RBL list  
>> because of
>> this. How do you guys deal with custommers sending bulk-mail? Are  
>> there
>> any rules in postfix to prevent it, maybe even delaying them in the  
>> queue?
>>
>> Thanks,
>>
> This may be OT here
>
> Outgoing spam scanning is a very good option. Unlike incoming , here  
> you
> dont have to catch all the spam. Just one spam caught , and you know  
> who
> is the culprit.
>
> What I do is to reduce the scanning I only scan messages sent to
> russia,china, taiwan etc. (based on domain tlds). Since legitimate
> traffic from my servers to these are much smaller they usually catch a
> lot of spam, with very little penalty of scanning. This works for me
> because most outbreaks are due to weak passwords or some virus.  
> Ofcourse
> YMMV
>
> One more thing you must do is monitor abuse complaints, Create  
> Feedback
> loops with aol, yahoo etc. (Unfortunately gmail doesnt seem to have
> one)
>
> Anyway you really dont have to worry too much. No one blacklists you
> because of just one or two spams inadvertently relayed thru your
> network.
> You just have to bother about customers who deliberately spam, we have
> had very bad experiences and since then we have been insisting on
> getting a bullet-proof TOS signed.


You nailed it.  You will get on a BL, nothing you can do about it.  
But if you are on the feedback loops, and most all BL's send you an  
email, so make sure you can get mail to abuse@ and postmater@, and  
check those.  As long as you follow through with the email reports,  
you will be able to give your customer one warning, and on the second  
time, you kick them off your server.

--
Scott * If you contact me off list replace talklists@ with scott@ *