You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Alexandre Chapellon <al...@mana.pf> on 2010/02/16 19:44:07 UTC
SA on outgoing SMTP
Hello the list,
I have a quite buggy customer network, full of zombie PCs that spends
all days sending spam and wasting the whole "reputation" of my networks.
As a result it sometimes become quite hard to delivers queues for
specific domains such as Yahoo!'s hosted ones. Indeed they have some
temp fail (blacklist) mechanism that forbid my servers to send messages
to them during hours.
Taht's why I would like to setup some ougoing filtering to avoid sending
too much spam through my mail relays. I think SA can help me in doing
so, but I know too it's not really intented to work this way. I guess SA
expects to work on MX hosts more than on smtp relays.
My prerequisites are mainly:
- STOP as much spam as possible at SMTP time (before queuing)
- Have NO (or very few) false positives cause I could not manage
telling thousands of users that they should *always_have_a_subject*,
*shouldn't_write_the_subject_in_CAPS* or anything else.
Further more I can't rely on RBL because a lot of my dyn IP address are
regularily listed on different blacklist.
Does anyone have already setup something like that and what specific
config/tools/plugin could be usefull for me.
If some one already done it.... does he/she have any statistics about
the efficiency of this setup.
Best regards.
Re: SA on outgoing SMTP
Posted by Charles Gregory <cg...@hwcn.org>.
Slightly OT. To get 'control' of what my MX does at SMTP time I installed
a simple SMTP daemon called 'Mail Avenger', which acts as a front end to
my spamassassin and postfix. It's scripting capabilties allow for such
interesting things as tracking the volume of mail sent by any one IP over
a given time period. Stuff like that. Primarily designed for use as an MX,
but no reason it couldn't help monitor/limit outgoing mail....
http://www.mailavenger.org
- C
On Tue, 16 Feb 2010, Alexandre Chapellon wrote:
> I have a quite buggy customer network, full of zombie PCs that spends all
> days sending spam and wasting the whole "reputation" of my networks.
> As a result it sometimes become quite hard to delivers queues for specific
> domains such as Yahoo!'s hosted ones. Indeed they have some temp fail
> (blacklist) mechanism that forbid my servers to send messages to them during
> hours.
> Taht's why I would like to setup some ougoing filtering to avoid sending too
> much spam through my mail relays. I think SA can help me in doing so, but I
> know too it's not really intented to work this way. I guess SA expects to
> work on MX hosts more than on smtp relays.
>
> My prerequisites are mainly:
> - STOP as much spam as possible at SMTP time (before queuing)
> - Have NO (or very few) false positives cause I could not manage telling
> thousands of users that they should *always_have_a_subject*,
> *shouldn't_write_the_subject_in_CAPS* or anything else.
>
> Further more I can't rely on RBL because a lot of my dyn IP address are
> regularily listed on different blacklist.
>
> Does anyone have already setup something like that and what specific
> config/tools/plugin could be usefull for me.
> If some one already done it.... does he/she have any statistics about the
> efficiency of this setup.
>
> Best regards.
>
Re: SA on outgoing SMTP
Posted by DAve <da...@pixelhammer.com>.
Alexandre,
To answer your first question, yes we filter outbound mail. We were once
in the same position as you are now and corrected the problem
successfully. All the advice given is good and I can attest that it will
work.
We first created a separate outbound service with authenticated smtps
added and then worked hard to convert all clients to the new service. We
went so far as to make it mandatory that all new clients were only
allowed to send mail if authenticated. Our support staff would change a
users MUA to authenticated connection if the client called support for
*any* reason.
We filter all messages at connection time and refuse the message if it
scores above the set SpamAssassin limit or contains a virus. The user
knows immediately their mail will not go out. When the client calls
support, the first thing support does is of course, change their MUA to
authenticated smtps.
We rate limit all outbound mail, exceed the messages per minute and we
block your connection until a sysadmin looks at the problem.
We limited recipients per message, first at 100, then we moved to 75,
now we are 50. Want more recipients? Purchase a mail list with verp from
us. A few complaints, a few clients changed to another provider, but the
problem stopped.
We have feedback loops setup and we read the messages everyday. We have
all our hosted domains postmaster mail sent to us, and we read it
everyday. We spot a problem and we have the client on the phone within
minutes. We have had to block a few clients until they cleaned up their
network/PC, but not very often anymore.
We now have *all* (100% except Nagios alerts) mail traffic flowing
through our filtered outbound servers. Clients, office, printers,
scan2mail, fax2mail, even the web servers use our outbound servers as
smart hosts.
Messages go through our outbound servers, or they do not leave our
network. We are not perfect, we still see some feedback (mostly bad
addresses and clueless recipients) but we are far better than we were
four years ago.
Listen to what the experts are telling you and implement their
suggestions. You may loose a client or two, but you will improve your
network and get better clients in return for your efforts.
DAve
--
"Posterity, you will know how much it cost the present generation to
preserve your freedom. I hope you will make good use of it. If you
do not, I shall repent in heaven that ever I took half the pains to
preserve it." John Adams
http://appleseedinfo.org
Re: SA on outgoing SMTP
Posted by SM <sm...@resistor.net>.
At 13:49 16-02-10, Alexandre Chapellon wrote:
>Mostly not but thoose who are doing so make my mail servers being
>blacklisted from time to times.
>(And I don't really care about dyn IP adresses being on blacklists... for now)
Your subnet will probably be blacklisted. As this is not the right
venue to talk about escalation, I won't get into that.
>This is what i am doing... but I'd like to know if someone has done
>it too and how efficient it is.
It can be quite efficient. If you are going to use a stock
installation, it may not be as efficient. The efficiency also
depends on the user-base.
>I don't want to set this up if It won't change my reputation and
>just cause some false positives.
It won't change your reputation overnight. You will also have to
overcome the growing pains if you have never used SpamAssassin.
>It definetly is when hitting the problem of false positive... I
>can't let a user thinking we sent his mail when we "wrongly" dropped it.
I am not talking about dropping mail. False positives _will_ happen.
Regards,
-sm
Re: SA on outgoing SMTP
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Alexandre Chapellon wrote:
> Le mardi 16 février 2010 à 12:46 -0800, SM a écrit :
>
>> Hi Alexandre,
>> At 10:44 16-02-10, Alexandre Chapellon wrote:
>>> I have a quite buggy customer network, full of zombie PCs that
>>> spends all days sending spam and wasting the whole "reputation" of my networks.
>> Do they send these messages through your mail server?
>
>
> Mostly not but thoose who are doing so make my mail servers being
> blacklisted from time to times.
> (And I don't really care about dyn IP adresses being on blacklists...
> for now)
>
No, you don't - but the rest of us care very much about getting the
garbage that those dyn IP addresses are sending out.
You need to adjust your attitude. I'm glad your at least trying to
do something about spam but it certainly appears that your only
interested in it insofar as it affects you, and you don't give a
rat's ass about how your network affects the rest of us.
Ted
Re: SA on outgoing SMTP
Posted by Kris Deugau <kd...@vianet.ca>.
Mark Martinec wrote:
> SA already has some awareness of mail flow direction (inbound vs.
> outbound) through its trusted_networks/internal_networks/msa_networks
> settings, and recognizes authentication signs in Received header fields,
> as well as its whitelist_bounce_relays awareness, so it should be able
> to deal with things like DUL blacklists correctly. Since you already
> have split mail paths, i.e. a dedicated MTA for outgoing mail, that's
> even easier, you can just turn off some dynamic blacklist lookups
> and adjust some other rules for mail submitted from internal networks
> or from authenticated roaming users.
FWIW, with properly-configured trusted_networks etc, I haven't seen
anything more than noise-level problems (one or two oddities every few
months; ~100K messages/day outbound). Some of that may be a higher
spam threshold for AUTH'ed mail (8 vs 5) too.
-kgd
Re: SA on outgoing SMTP
Posted by Mark Martinec <Ma...@ijs.si>.
On Wednesday February 17 2010 00:43:04 Alexandre Chapellon wrote:
> I'd like to re-focused to my initial questions: "does SA on outgoing
> smtp needs specific tweaks? Is it a good idea and does any body already
> set it up?"
SA already has some awareness of mail flow direction (inbound vs.
outbound) through its trusted_networks/internal_networks/msa_networks
settings, and recognizes authentication signs in Received header fields,
as well as its whitelist_bounce_relays awareness, so it should be able
to deal with things like DUL blacklists correctly. Since you already
have split mail paths, i.e. a dedicated MTA for outgoing mail, that's
even easier, you can just turn off some dynamic blacklist lookups
and adjust some other rules for mail submitted from internal networks
or from authenticated roaming users.
Is it a good idea to check outgoing mail? It certainly is, as
you are already well aware. Mail filtering on a MTA should be
combined with blocking outgoing connections to port 25, as
already noted by several posters. Allow outgoing connections
to mail submission port 587 and to a legacy port 465, but allow
outgoing connections to 25 only based on explicit requests from
users, and block it by default.
Mail submission rate limiting is very effective against traffic
bursts from infected PCs. As you are using Postfix, see its
anvil(8) service, along with its settings:
anvil_rate_time_unit
smtpd_client_connection_count_limit
smtpd_client_connection_rate_limit
smtpd_client_message_rate_limit
smtpd_client_event_limit_exceptions
A more fine-grained rate control is possible through policy servers,
there are a couple of them much praised - check the postfix user ML.
As for interfacing SpamAssassin with a Postfix MTA there are some
choices, perhaps the most straightforward is using amavisd in
place of spamd because it speaks a SMTP protocol directly on
its input and output sides, interfacing naturally with Postfix
without resorting to pipes, temporary files, scripts, etc.
Just turn off anything not needed (like decoding mail), and
you end up basically with a spamd lookalike speaking SMTP.
The setup offers a fast interface to virus scanners such as
clamd, to protect against outbound virus outbreaks too.
As a bonus, such setup can offer DKIM signing, and a 'pen-pals'
feature when inbound and outbound content filtering uses the same
SQL database: grants some bonus score points to inbound replies
to previous outbound mail with reversed sender/recipient addresses,
similar to an automatic soft-whitelisting, which gradually fades
away with time.
Depending on mail rate and your needs, you may choose a more
common and robust post-queue content filtering setup, or go for
a pre-queue proxy content filtering. For improved robustness
of a pre-queue setup look for Postfix 2.7.0 with its
"smtpd_proxy_options=speed_adjust" feature, the coming
amavisd-new 2.7.0, and SpamAssassin 3.3.0 - the combination
of new features in all three products is really geared to
much better support pre-queue setups.
Mark
Re: SA on outgoing SMTP
Posted by Frank Heydlauf <fh...@lf.net>.
Hi,
On Tue, Feb 16, 2010 at 04:44:05PM -1000, Alexandre Chapellon wrote:
> Le mercredi 17 fe'vrier 2010 a` 01:38 +0100, Karsten Bra:ckelmann a e'crit :
...
> The one using SMTP-AUTH to relay spam through my servers are most of the time
> IP address outside of my network... I imagine they have credentials sent by
> trojan or stuff like this.
brute-force password-scan is cheap and easy with most MTAs :-(
Change mail-password of abused accounts immediately and
in any case of abuse.
Make it difficult to pwd-scan your server (limit failed passwd
attempts per time).
> But I also have others that are machines inside my network using AUTH. If you
> want to take a look at it, I can forward one complaint.
Is this correct?
You have authenticated users inside and outside of your
network sending spam. In other words: you know the user - or
at least the users account sending spam.
So you have any possibility to close or limit the account,
inform the user etc.
Having this, how could spamassassin help you?
o Knowing about the abuse maybe 2 hours before you get
complaints? yes.
o Tagging outgoing messages as spam? That's ridiculous.
o Blocking mails with high spam-scores and routing the others?
- Since SA will never fetch any single spam (I guess some 10%
false negative when feeded directly from a spam-bot (new
pattern, no hashes yet, no IP blacklists possible) and
without causing excessive FPs) you'll still send out enough
spam to get complaints or to get blacklisted.
- It does not help your customers with their obsessed PCs
Yes, most Customers like to be informed about an infection.
- It does not help the rest of us since the Bot in the
obsessed PC may send direct to our MTAs tomorrow.
Summarized:
If you setup SA outgoing for blocking spam without stopping
your users to produce/relay spam and without stopping your
smtp-auth accounts getting abused
- you'll still have complaints from your customers about
blocked mails - now additional from your own servers
false positives
- your mailhost still will be blacklisted
- your Network still will be blacklisted
- all others still will get spam from your net (even if
less directly sent from your server)
- your customers still have obsessed PCs with all dangers
of losing private data, having the pc abused for filesharing,
DoS, hacking, beeing sued about this...
But it may save your ass for 2 month if your boss is after you.
That's no affordable scenario in my eyes, sorry.
--
Greets
Frank
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mercredi 17 février 2010 à 01:38 +0100, Karsten Bräckelmann a écrit :
> On Tue, 2010-02-16 at 13:43 -1000, Alexandre Chapellon wrote:
> > Le mardi 16 février 2010 à 23:07 +0100, Karsten Bräckelmann a écrit :
>
> > > Hmm, wait. Are you saying the bots are using your infrastructure, rather
> > > than the most common direct to MX? Or are you saying your customers are
> > > actively spamming themselves?
> >
> > If I take a look at the feedback loop i received I can see that some
> > bots are sending directly to mx and somes other are sending to my
> > mails relay (probably using outlook connectors or others)
>
> Authenticated!?
The one using SMTP-AUTH to relay spam through my servers are most of the
time IP address outside of my network... I imagine they have credentials
sent by trojan or stuff like this.
But I also have others that are machines inside my network using AUTH.
If you want to take a look at it, I can forward one complaint.
>
> Also, do you care about those sending direct to MX?
To track direct to MX I will monitor feedback loop and complaints (from
spamcop and others) and send warning to my customers..
>
> > > AFAIK bots still don't abuse MUA credentials on the infected machine to
> > > authenticate against the outbound SMTP. A policy change to offer SMTP
> > > only with auth and TLS in 3 months time should be easy to tell your
> > > customers.
> >
> > I already set up SMTP-AUTH few month ago but it's not mandatory yet
> > and most of my users didn't configured it yet.
>
> This is a good time to have it mandatory in 2 months, don't you think?
> Either auth, or use some external SMTP. No excuse, no mercy.
lol... I can't afford "no excuse, no mercy"... But I will do my best to
make the life of people not using auth harder and harder every day.
>
> > > What blacklists are we talking about?
> >
> > I'd like to re-focused to my initial questions:
>
> I'd like to get an answer to the question.
Not public blacklists but for example Yahoo!'s servers spends most of
its days replying "defered temporarily due user complaints' o our
relays.
>
> Yes, the blacklist might make a hell of a difference. And the answer to
> this might even make a difference, if you really want to filter outbound
> mail through SA, or if there are other alternatives.
>
> > "does SA on outgoing smtp needs specific tweaks? Is it a good idea and
> > does any body already set it up?"
>
> Yes, it needs specific tweaks. As has been pointed out before. For
> starters, you do not want any PBL style blacklists. Given the bot
> infected picture of your customers you paint, you definitely don't want
> any XBL style blacklists either.
>
> Oh, and of course the yet-unnamed ones *you* are listed on... See?
>
> Good idea? Depends. For some, yes. Someone done it before? Definitely.
> Did you google or check this list's archives?
>
Yes but if can find people saying "i'm doing thing", I can't find
feedback on how it worked ou...
> guenther
>
>
Re: SA on outgoing SMTP
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-16 at 13:43 -1000, Alexandre Chapellon wrote:
> Le mardi 16 février 2010 à 23:07 +0100, Karsten Bräckelmann a écrit :
> > Hmm, wait. Are you saying the bots are using your infrastructure, rather
> > than the most common direct to MX? Or are you saying your customers are
> > actively spamming themselves?
>
> If I take a look at the feedback loop i received I can see that some
> bots are sending directly to mx and somes other are sending to my
> mails relay (probably using outlook connectors or others)
Authenticated!?
Also, do you care about those sending direct to MX?
> > AFAIK bots still don't abuse MUA credentials on the infected machine to
> > authenticate against the outbound SMTP. A policy change to offer SMTP
> > only with auth and TLS in 3 months time should be easy to tell your
> > customers.
>
> I already set up SMTP-AUTH few month ago but it's not mandatory yet
> and most of my users didn't configured it yet.
This is a good time to have it mandatory in 2 months, don't you think?
Either auth, or use some external SMTP. No excuse, no mercy.
> > What blacklists are we talking about?
>
> I'd like to re-focused to my initial questions:
I'd like to get an answer to the question.
Yes, the blacklist might make a hell of a difference. And the answer to
this might even make a difference, if you really want to filter outbound
mail through SA, or if there are other alternatives.
> "does SA on outgoing smtp needs specific tweaks? Is it a good idea and
> does any body already set it up?"
Yes, it needs specific tweaks. As has been pointed out before. For
starters, you do not want any PBL style blacklists. Given the bot
infected picture of your customers you paint, you definitely don't want
any XBL style blacklists either.
Oh, and of course the yet-unnamed ones *you* are listed on... See?
Good idea? Depends. For some, yes. Someone done it before? Definitely.
Did you google or check this list's archives?
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA on outgoing SMTP
Posted by Charles Gregory <cg...@hwcn.org>.
On Wed, 17 Feb 2010, Kris Deugau wrote:
> My experience has been that Outlook in particular (not Outlook Express
> or its descendant Windows (Live) Mail) does NOT in fact display SMTP
> error messages exactly as the server spits them out. :(
Sorry. You've heard that old phrase "goes without saying"?
Well, I didn't say it. (smile)
Where Microsoft and error messages are concerned, I consider
it par for the course that what is reported to the user will be a
miserable distortion of whatever actual error occurred. But just the same,
the user will know that *something* has gone wrong with their mail.
Obviously the fewer FP's the better when dealing with confusing error
messages.... :)
- C
Re: SA on outgoing SMTP
Posted by Kris Deugau <kd...@vianet.ca>.
Charles Gregory wrote:
> ... but any legitimate mail that is blocked will
> result in their MUA (Outlook) displaying an error message. This is GOOD. :)
My experience has been that Outlook in particular (not Outlook Express
or its descendant Windows (Live) Mail) does NOT in fact display SMTP
error messages exactly as the server spits them out. :( A few other
MUAs also commit this stupidity.
(I agree with your main point about rejecting while the connection is
open instead of generating DSNs for spammy mail though.)
-kgd
Re: SA on outgoing SMTP
Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 16 Feb 2010, Alexandre Chapellon wrote:
> I'd like to re-focused to my initial questions: "does SA on outgoing smtp
> needs specific tweaks? Is it a good idea and does any body already set it
> up?"
In answer to 'is it a good idea', please insure that whatever mechanism
you put in place operates at SMTP time.
Do NOT (big heavy sledgehammer NOT) 'accept' a mail into your MTA before
checknig it. Otherwise you will generate the WORST kind of backscatter
when you try to 'reject' the mail. Obviously you cannot silently discard
your user's mail, so you *must* 'reject' it, so be sure to do this at the
SMTP gateway. Spambots will ignore the reject. The users won't even know
anything happened, but any legitimate mail that is blocked will result in
their MUA (Outlook) displaying an error message. This is GOOD. :)
If you cannot manage the technical feat of running spamassassin during the
SMTP 'data' phase, and have to 'bounce' messages, then NO this is just a
terribly bad idea. But not bad because of spamassassin. Bad because of the
potential backscatter being sent OUT from your server to the forged
senders of all your spam.
- Charles
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mardi 16 février 2010 à 23:07 +0100, Karsten Bräckelmann a écrit :
> On Tue, 2010-02-16 at 11:49 -1000, Alexandre Chapellon wrote:
> > > >I have a quite buggy customer network, full of zombie PCs that
> > > >spends all days sending spam and wasting the whole "reputation" of my networks.
> > >
> > > Do they send these messages through your mail server?
> >
> > Mostly not but thoose who are doing so make my mail servers being
> > blacklisted from time to times.
> > (And I don't really care about dyn IP adresses being on blacklists...
> > for now)
>
> Hmm, wait. Are you saying the bots are using your infrastructure, rather
> than the most common direct to MX? Or are you saying your customers are
> actively spamming themselves?
If I take a look at the feedback loop i received I can see that some
bots are sending directly to mx and somes other are sending to my mails
relay (probably using outlook connectors or others)
> AFAIK bots still don't abuse MUA credentials on the infected machine to
> authenticate against the outbound SMTP. A policy change to offer SMTP
> only with auth and TLS in 3 months time should be easy to tell your
> customers.
I already set up SMTP-AUTH few month ago but it's not mandatory yet and
most of my users didn't configured it yet.
> Any mail traffic not relaying via your SMTP server should NOT get you on
> any blacklist. Serious blacklist, that is.
>
If talking about blacklist, of course the problem is spam my server
relay.
> What blacklists are we talking about?
I'd like to re-focused to my initial questions: "does SA on outgoing
smtp needs specific tweaks? Is it a good idea and does any body already
set it up?"
thanks
Re: SA on outgoing SMTP
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-16 at 11:49 -1000, Alexandre Chapellon wrote:
> > >I have a quite buggy customer network, full of zombie PCs that
> > >spends all days sending spam and wasting the whole "reputation" of my networks.
> >
> > Do they send these messages through your mail server?
>
> Mostly not but thoose who are doing so make my mail servers being
> blacklisted from time to times.
> (And I don't really care about dyn IP adresses being on blacklists...
> for now)
Hmm, wait. Are you saying the bots are using your infrastructure, rather
than the most common direct to MX? Or are you saying your customers are
actively spamming themselves?
AFAIK bots still don't abuse MUA credentials on the infected machine to
authenticate against the outbound SMTP. A policy change to offer SMTP
only with auth and TLS in 3 months time should be easy to tell your
customers.
Any mail traffic not relaying via your SMTP server should NOT get you on
any blacklist. Serious blacklist, that is.
What blacklists are we talking about?
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mardi 16 février 2010 à 12:46 -0800, SM a écrit :
> Hi Alexandre,
> At 10:44 16-02-10, Alexandre Chapellon wrote:
> >I have a quite buggy customer network, full of zombie PCs that
> >spends all days sending spam and wasting the whole "reputation" of my networks.
>
> Do they send these messages through your mail server?
Mostly not but thoose who are doing so make my mail servers being
blacklisted from time to times.
(And I don't really care about dyn IP adresses being on blacklists...
for now)
> >As a result it sometimes become quite hard to delivers queues for
> >specific domains such as Yahoo!'s hosted ones. Indeed they have some
> >temp fail (blacklist) mechanism that forbid my servers to send
> >messages to them during hours.
> >Taht's why I would like to setup some ougoing filtering to avoid
> >sending too much spam through my mail relays. I think SA can help me
> >in doing so, but I know too it's not really intented to work this
> >way. I guess SA expects to work on MX hosts more than on smtp relays.
>
> You can still run some SpamAssassin tests to catch some of the spam.
This is what i am doing... but I'd like to know if someone has done it
too and how efficient it is.
I don't want to set this up if It won't change my reputation and just
cause some false positives.
>
> >My prerequisites are mainly:
> > - STOP as much spam as possible at SMTP time (before queuing)
>
> As this is outgoing, post-SMTP filtering is not much of an issue.
It definetly is when hitting the problem of false positive... I can't
let a user thinking we sent his mail when we "wrongly" dropped it.
> >Further more I can't rely on RBL because a lot of my dyn IP address
> >are regularily listed on different blacklist.
>
> Relying on other people to tell you that there is a problem on your
> network is not a good idea.
>
> Sign up for feedback loops. Rate limit mail submissions or set up
> triggers to identify abnormalities. You may also wish to do traffic
> flow analysis to see what's going through your network.
Indeed Flow analisys is something I didn't think about but which could
be helpful
regards
>
> Regards,
> -sm
>
Re: SA on outgoing SMTP
Posted by SM <sm...@resistor.net>.
Hi Alexandre,
At 10:44 16-02-10, Alexandre Chapellon wrote:
>I have a quite buggy customer network, full of zombie PCs that
>spends all days sending spam and wasting the whole "reputation" of my networks.
Do they send these messages through your mail server?
>As a result it sometimes become quite hard to delivers queues for
>specific domains such as Yahoo!'s hosted ones. Indeed they have some
>temp fail (blacklist) mechanism that forbid my servers to send
>messages to them during hours.
>Taht's why I would like to setup some ougoing filtering to avoid
>sending too much spam through my mail relays. I think SA can help me
>in doing so, but I know too it's not really intented to work this
>way. I guess SA expects to work on MX hosts more than on smtp relays.
You can still run some SpamAssassin tests to catch some of the spam.
>My prerequisites are mainly:
> - STOP as much spam as possible at SMTP time (before queuing)
As this is outgoing, post-SMTP filtering is not much of an issue.
>Further more I can't rely on RBL because a lot of my dyn IP address
>are regularily listed on different blacklist.
Relying on other people to tell you that there is a problem on your
network is not a good idea.
Sign up for feedback loops. Rate limit mail submissions or set up
triggers to identify abnormalities. You may also wish to do traffic
flow analysis to see what's going through your network.
Regards,
-sm
Re: SA on outgoing SMTP
Posted by Mark Martinec <Ma...@ijs.si>.
> For improved robustness of a pre-queue setup look for Postfix 2.7.0
> with its "smtpd_proxy_options=speed_adjust" feature
Btw, the Postfix 2.7.0 also brings a feature which may be valuable
to you: an outgoing MTA can have multiple IP addresses on its interface,
and you can choose from which IP address a mail will be sent based on
some criteria you establish to differentiate your customers.
Postfix 2.7.0 release notes:
- Support for reputation management based on the local SMTP client
IP address. This is typically implemented with "FILTER transportname:"
actions in access maps or header/body checks, and mail delivery
transports in master.cf with unique smtp_bind_address values.
For example, let mail submitted by authenticated mail clients on
a mail submission port go out on one IP address, then let mail
from some trustworthy clients (small offices) with static addresses
go out with a second IP address, and let the third IP address
be used for everybody else.
Eventually recipients may be able to assign reputations to each
of your outgoing IP addresses, perhaps treating the first two
more favourably or even whitelisting them, but certainly there
will be less chance they end up on some blacklist.
Mark
Re: SA on outgoing SMTP
Posted by Martin Gregorie <ma...@gregorie.org>.
On Wed, 2010-02-17 at 02:07 +0100, Mark Martinec wrote:
> > > Look at grey-listing as well. It should be useful if it can distinguish
> > > between the user's MUA (or private MTA) and a bot.
>
> MUAs generally don't cope well with greylisting, as they lack good
> mechanisms for automatic retries - so I'm not sure that's a good advice.
>
I wondered about that as I wrote it. IIRC I've seen the equivalent while
I was working out how to set up my system. The likes of Evolution tend
to report the error and leave the message sitting in the outbox. Thats a
good indication of trouble provided you notice its still there.
> T&C = terms and conditions. It's your call to set rules of the game.
>
> Tell the clients that for a little effort on their part turning on
> the SASL authentication and submitting through standard mail submission
> ports, they will be gaining a better service with more reliable
> acceptance rate by their recipients.
>
I was also suggesting something along the lines of "we'll still permit
non-authenticated connections but we'll charge 100% more for that
privilege".
Martin
Re: SA on outgoing SMTP
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Mark Martinec wrote:
>>> Look at grey-listing as well. It should be useful if it can distinguish
>>> between the user's MUA (or private MTA) and a bot.
>
> MUAs generally don't cope well with greylisting, as they lack good
> mechanisms for automatic retries - so I'm not sure that's a good advice.
>
greylist-milter exempts auth-smtp senders, obviously this is a Sendmail
thing, I don't know about other greylisting programs.
>>> Why on earth not? You control T&C for your ISP and can change them. If
>>> necessary you can keep existing charges for authenticated connections
>>> and raise them for those who don't convert.
>> My english is not good enough to understand this sorry :p
>
> T&C = terms and conditions. It's your call to set rules of the game.
>
> Tell the clients that for a little effort on their part turning on
> the SASL authentication and submitting through standard mail submission
> ports, they will be gaining a better service with more reliable
> acceptance rate by their recipients.
>
> Here is another good incentive to use a mail submission service of
> a domain matching their From address: they gain a valid DKIM signature
> on their outgoing mail. For example: when using a gmail From address
> it pays off to submit mail to google on port 587 - the message gains
> a gmail signature. Sending directly from a home or small office machine
> and using a gmail or yahoo From address is likely to be treated as
> second-class mail by recipients (not trustworthy, likely to gain
> some spam score points). The same (but in reverse) applies to outgoing
> mail using your ISP's domain: it pays off to submit it to ISP's
> mail submission service, this is the only way to gain its DKIM signature.
> Increasing number of domains (like yahoo) treat mail with a valid
> DKIM signature favourably.
>
Just keep in mind that he's in a guns-or-butter problem.
He's making guns now (network wide open, causing customer problems,
the upside is client configuration is simple) and he wants to make
butter (network tight, no customer problems, at the cost of increased
client configuration complexity)
During the time that he's transitioning from the guns to the butter
his network is doing both things - and so it has all of the bad
problems of the gunmaking, (spammers) plus all of the downsides of the
butter making (basically increased work to configure mail clients) yet
he is getting none of the benefits of either the gunmaking (he's no
longer getting easy client configuration) or the buttermaking (a
tight network)
It takes someone very strongly focused on the end result, who
believes in what they are doing, and who has the support of their
owners/upper managers, to make it through such a transition. And
there will be scars. They WILL lose customers. Of course, doing
nothing they lose customers too - but since the customer loss isn't
coming as a result of anyone doing anything, (but rather of people
failing to do something) it's hard for upper managers of the
pointy-haired type to levy blame, so people in those situations
tend to not get fired.
Sometimes companies will hire "sacrificial lambs" This is common
in government. For example a few years ago our local school district
needed to close some schools (political suicide for anyone) due
to declining enrollment, so they hired some $200K+ Harvard-educated,
resume-as-long-as-my-dick type to come
in and kick ass - and kick ass she did. She closed at least a
dozen schools down before the losers managed to band together and
toss her out. Of course, now the school district had the perfect
excuse to NOT reopen the schools (too expensive to restart them
because they had been closed for too long) and after the obligatory
public chest-beating and wailing about how we are so sorry that your kid
can't go to the school you went to 30 years ago when you were knee-high
to a grasshopper, a few years later the losing parents had completed
cycling their kids through the school system, and nowadays no parent
with kids in the system even remembers the names of any of the
closed schools, let alone where they were located.
If his management won't let him do what it takes, he might need
to hire a "sacrificial lamb" consulting firm, too.
Ted
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mercredi 17 février 2010 à 02:07 +0100, Mark Martinec a écrit :
> > > Look at grey-listing as well. It should be useful if it can distinguish
> > > between the user's MUA (or private MTA) and a bot.
>
> MUAs generally don't cope well with greylisting, as they lack good
> mechanisms for automatic retries - so I'm not sure that's a good advice.
>
> > > Why on earth not? You control T&C for your ISP and can change them. If
> > > necessary you can keep existing charges for authenticated connections
> > > and raise them for those who don't convert.
> >
> > My english is not good enough to understand this sorry :p
>
> T&C = terms and conditions. It's your call to set rules of the game.
>
> Tell the clients that for a little effort on their part turning on
> the SASL authentication and submitting through standard mail submission
> ports, they will be gaining a better service with more reliable
> acceptance rate by their recipients.
>
> Here is another good incentive to use a mail submission service of
> a domain matching their From address: they gain a valid DKIM signature
> on their outgoing mail. For example: when using a gmail From address
> it pays off to submit mail to google on port 587 - the message gains
> a gmail signature. Sending directly from a home or small office machine
> and using a gmail or yahoo From address is likely to be treated as
> second-class mail by recipients (not trustworthy, likely to gain
> some spam score points). The same (but in reverse) applies to outgoing
> mail using your ISP's domain: it pays off to submit it to ISP's
> mail submission service, this is the only way to gain its DKIM signature.
> Increasing number of domains (like yahoo) treat mail with a valid
> DKIM signature favourably.
This really sounds great. More reliable mail for my customer, and a
cleaner network for me. Thank you!!!!
> Mark
Re: SA on outgoing SMTP
Posted by Mark Martinec <Ma...@ijs.si>.
> > Look at grey-listing as well. It should be useful if it can distinguish
> > between the user's MUA (or private MTA) and a bot.
MUAs generally don't cope well with greylisting, as they lack good
mechanisms for automatic retries - so I'm not sure that's a good advice.
> > Why on earth not? You control T&C for your ISP and can change them. If
> > necessary you can keep existing charges for authenticated connections
> > and raise them for those who don't convert.
>
> My english is not good enough to understand this sorry :p
T&C = terms and conditions. It's your call to set rules of the game.
Tell the clients that for a little effort on their part turning on
the SASL authentication and submitting through standard mail submission
ports, they will be gaining a better service with more reliable
acceptance rate by their recipients.
Here is another good incentive to use a mail submission service of
a domain matching their From address: they gain a valid DKIM signature
on their outgoing mail. For example: when using a gmail From address
it pays off to submit mail to google on port 587 - the message gains
a gmail signature. Sending directly from a home or small office machine
and using a gmail or yahoo From address is likely to be treated as
second-class mail by recipients (not trustworthy, likely to gain
some spam score points). The same (but in reverse) applies to outgoing
mail using your ISP's domain: it pays off to submit it to ISP's
mail submission service, this is the only way to gain its DKIM signature.
Increasing number of domains (like yahoo) treat mail with a valid
DKIM signature favourably.
Mark
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mercredi 17 février 2010 à 01:52 +0000, Martin Gregorie a écrit :
> On Tue, 2010-02-16 at 14:10 -1000, Alexandre Chapellon wrote:
> > Le mardi 16 février 2010 à 23:54 +0000, Martin Gregorie a écrit :
> > > Where's the problem? You'll need to write some code to interpret SA's
> > > spam markers anyway, so it can easily add a log message to maillog. Then
> > > its trivial to extend logwatch to scan the maillog and generate messages
> > > to spamiferous users.
> > Believe me I can't. If I reject mail, user have to be informed when I
> > do it and not even 12 hours after.
> >
> Surely that depends on the customer? For a normal customer (private,
> small company) a once a day reminder about spam may be good enough.
>
> Remember that undeliverable mail can and does get returned up to 4-5
> days later.
Yes but most of the time (here) undeliverable mails are undeliverable
because of recipient over quota, wrong mx records on dst domain or
things like this... I can explain this to my customer. By cons I cannot
tell him we silently droped your mail this morning cause it looked like
spam... at least I don't feel confortable with this.
> > I have governemental customer, and they are really... demanding.
> >
> If you normally configure your routers to block direct connections via
> port 25 you can equally configure the router to allow large or demanding
> customers with static IPs to use direct connections but you should make
> it quite clear that they are then responsible for their own outbound
> spam filtering and inbound filtering too, on the grounds that you don't
> want to be responsible for FPs interfering with their business.
>
>
> Martin
>
>
>
> 1)
> > >
> > >
> > > Martin
> > >
> > >
> >
>
Re: SA on outgoing SMTP
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2010-02-16 at 14:10 -1000, Alexandre Chapellon wrote:
> Le mardi 16 février 2010 à 23:54 +0000, Martin Gregorie a écrit :
> > Where's the problem? You'll need to write some code to interpret SA's
> > spam markers anyway, so it can easily add a log message to maillog. Then
> > its trivial to extend logwatch to scan the maillog and generate messages
> > to spamiferous users.
> Believe me I can't. If I reject mail, user have to be informed when I
> do it and not even 12 hours after.
>
Surely that depends on the customer? For a normal customer (private,
small company) a once a day reminder about spam may be good enough.
Remember that undeliverable mail can and does get returned up to 4-5
days later.
> I have governemental customer, and they are really... demanding.
>
If you normally configure your routers to block direct connections via
port 25 you can equally configure the router to allow large or demanding
customers with static IPs to use direct connections but you should make
it quite clear that they are then responsible for their own outbound
spam filtering and inbound filtering too, on the grounds that you don't
want to be responsible for FPs interfering with their business.
Martin
1)
> >
> >
> > Martin
> >
> >
>
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mardi 16 février 2010 à 23:54 +0000, Martin Gregorie a écrit :
> On Tue, 2010-02-16 at 11:38 -1000, Alexandre Chapellon wrote:
> > Le mardi 16 février 2010 à 20:29 +0000, Martin Gregorie a écrit :
> > > On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote:
> > > > Hello the list,
> > > >
> > > > I have a quite buggy customer network, full of zombie PCs that spends
> > > > all days sending spam and wasting the whole "reputation" of my
> > > > networks.
> > > >
> > > 1) Are you already using separate inbound and outbound mail servers?
> > >
> > yes of course
> >
> OK, so nothing is stopping you from running separate inbound and
> outbound SA rule sets. If you include spamc in your SMTP-time processing
> you can easily reject spam with 5xx responses. Granted a spam-bot will
> consume any directed at it, but if a FP reject is returned to the user's
> MUA he should see it.
>
> Look at grey-listing as well. It should be useful if it can distinguish
> between the user's MUA (or private MTA) and a bot. Better yet, as others
> have suggested, swap over to using SMTP authentication and TLS. Once
> you've blocked direct outward SMTP, using authenticated SMTP will also
> stop the bots in their tracks.
thanks
> > I can't block users from sendin directly.... I am an ISP my users are
> > free to use another relay than mine... eg google or yahoo or some
> > mails relay of their own hosted i don't know where.
> >
> Why on earth not? You control T&C for your ISP and can change them. If
> necessary you can keep existing charges for authenticated connections
> and raise them for those who don't convert.
>
My english is not good enough to understand this sorry :p
> > > - silently discard the spam and tell him you've done so on a daily basis
> > I don't want to do something like this.
> >
> Where's the problem? You'll need to write some code to interpret SA's
> spam markers anyway, so it can easily add a log message to maillog. Then
> its trivial to extend logwatch to scan the maillog and generate messages
> to spamiferous users.
Believe me I can't. If I reject mail, user have to be informed when I do
it and not even 12 hours after.
I have governemental customer, and they are really... demanding.
>
>
> Martin
>
>
Re: SA on outgoing SMTP
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2010-02-16 at 11:38 -1000, Alexandre Chapellon wrote:
> Le mardi 16 février 2010 à 20:29 +0000, Martin Gregorie a écrit :
> > On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote:
> > > Hello the list,
> > >
> > > I have a quite buggy customer network, full of zombie PCs that spends
> > > all days sending spam and wasting the whole "reputation" of my
> > > networks.
> > >
> > 1) Are you already using separate inbound and outbound mail servers?
> >
> yes of course
>
OK, so nothing is stopping you from running separate inbound and
outbound SA rule sets. If you include spamc in your SMTP-time processing
you can easily reject spam with 5xx responses. Granted a spam-bot will
consume any directed at it, but if a FP reject is returned to the user's
MUA he should see it.
Look at grey-listing as well. It should be useful if it can distinguish
between the user's MUA (or private MTA) and a bot. Better yet, as others
have suggested, swap over to using SMTP authentication and TLS. Once
you've blocked direct outward SMTP, using authenticated SMTP will also
stop the bots in their tracks.
> I can't block users from sendin directly.... I am an ISP my users are
> free to use another relay than mine... eg google or yahoo or some
> mails relay of their own hosted i don't know where.
>
Why on earth not? You control T&C for your ISP and can change them. If
necessary you can keep existing charges for authenticated connections
and raise them for those who don't convert.
> > - silently discard the spam and tell him you've done so on a daily basis
> I don't want to do something like this.
>
Where's the problem? You'll need to write some code to interpret SA's
spam markers anyway, so it can easily add a log message to maillog. Then
its trivial to extend logwatch to scan the maillog and generate messages
to spamiferous users.
Martin
Re: SA on outgoing SMTP
Posted by Bowie Bailey <Bo...@BUC.com>.
Alexandre Chapellon wrote:
> Le mardi 16 février 2010 à 20:29 +0000, Martin Gregorie a écrit :
>> Obvious choices for (4), in order of hitting the infected user with a
>> successively bigger clue stick, are:
>>
>> - silently discard the spam,
>> but you'll also throw away false positives.
>>
>
> Using before queuing filtering (on postfix) I reject the mail at SMTP
> time so the client gets an error (550 i guess) an so is aware (as far
> as a user can be aware of anything) his mail has been refused.
>
>> - silently discard the spam and tell him you've done so on a daily basis
>>
> I don't want to do something like this.
Daily notifications might be a good idea. If there is a spam-bot on the
user's computer, he will not see the SMTP rejections. The only way he
will know he is infected is if you let him know (assuming the generic
clueless user here). Sending an email on a daily (or weekly) basis to
let him know that there is spam coming from his computer along with a
support number to call or a link to an FAQ of some sort would probably
be useful.
--
Bowie
Re: SA on outgoing SMTP
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-16 at 11:38 -1000, Alexandre Chapellon wrote:
> Le mardi 16 février 2010 à 20:29 +0000, Martin Gregorie a écrit :
> > > I have a quite buggy customer network, full of zombie PCs that spends
> > > all days sending spam and wasting the whole "reputation" of my
> > > networks.
> >
> > 1) Are you already using separate inbound and outbound mail servers?
>
> yes of course
> > 3) Do you require all outbound mail to go through your servers and have
> > you blocked users from sending outbound mail directly?
>
> I can't block users from sendin directly.... I am an ISP my users are
> free to use another relay than mine... eg google or yahoo or some
> mails relay of their own hosted i don't know where.
This may just be me being confused today, but -- if your users are free
to use external SMTP servers on port 25 (which, as you stated probably
is a major part or your problem, given you mentioned bots), how exactly
is your hypothetical SA bastion server supposed to filter them?
I mean, the bots won't talk to your server, just because you ask nicely.
Enforced transparent SMTP proxy for all outgoing connections to port 25?
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
Le mardi 16 février 2010 à 20:29 +0000, Martin Gregorie a écrit :
> On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote:
> > Hello the list,
> >
> > I have a quite buggy customer network, full of zombie PCs that spends
> > all days sending spam and wasting the whole "reputation" of my
> > networks.
> >
> 1) Are you already using separate inbound and outbound mail servers?
>
yes of course
> 2) If not, does your mail server have any way of distinguishing the
> inbound and outbound streams (i.e., are your users sending on the
> standard SMTP port or on another one)?
>
> 3) Do you require all outbound mail to go through your servers and have
> you blocked users from sending outbound mail directly?
I can't block users from sendin directly.... I am an ISP my users are
free to use another relay than mine... eg google or yahoo or some mails
relay of their own hosted i don't know where.
> 4) When you catch outgoing spam what do you want to do about it?
>
DROP!
> Obvious choices for (4), in order of hitting the infected user with a
> successively bigger clue stick, are:
>
> - silently discard the spam,
> but you'll also throw away false positives.
Using before queuing filtering (on postfix) I reject the mail at SMTP
time so the client gets an error (550 i guess) an so is aware (as far as
a user can be aware of anything) his mail has been refused.
> - silently discard the spam and tell him you've done so on a daily basis
I don't want to do something like this.
>
> - tell your user he's infected and send all the spam back to him
>
> - tell your user he's infected, bin the spam and cut him off until
> his PC is clean.
I will, based on feedback loop mail processing. But that's another
stuff.
> If you haven't decided what to do with the outbound spam yet, it would
> be a good idea to work that out before doing anything.
>
> If (1) or (2) are true, you can run a separate copy of SA for outbound
> mail, use a different rule set from the one you use on inbound mail,
> and/or disable RBL checks on it. Since you know where the mail is coming
> from, there's little point in wasting cycles with RBL checks unless you
> want to use them to spot forged sender addresses.
>
> The answers to these questions should help you figure out what you want
> to do about users with infected machines and help you decide what to do
> with the spam they're sending. It will also give us some idea of what to
> suggest.
Indeed thoose questions (I already asked myself) are the first to
setting up something efficient and too borring for users.
It's good to see people who try to have a "global" view of the problem.
>
>
> Martin
>
>
Re: SA on outgoing SMTP
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2010-02-16 at 08:44 -1000, Alexandre Chapellon wrote:
> Hello the list,
>
> I have a quite buggy customer network, full of zombie PCs that spends
> all days sending spam and wasting the whole "reputation" of my
> networks.
>
1) Are you already using separate inbound and outbound mail servers?
2) If not, does your mail server have any way of distinguishing the
inbound and outbound streams (i.e., are your users sending on the
standard SMTP port or on another one)?
3) Do you require all outbound mail to go through your servers and have
you blocked users from sending outbound mail directly?
4) When you catch outgoing spam what do you want to do about it?
Obvious choices for (4), in order of hitting the infected user with a
successively bigger clue stick, are:
- silently discard the spam,
but you'll also throw away false positives.
- silently discard the spam and tell him you've done so on a daily basis
- tell your user he's infected and send all the spam back to him
- tell your user he's infected, bin the spam and cut him off until
his PC is clean.
If you haven't decided what to do with the outbound spam yet, it would
be a good idea to work that out before doing anything.
If (1) or (2) are true, you can run a separate copy of SA for outbound
mail, use a different rule set from the one you use on inbound mail,
and/or disable RBL checks on it. Since you know where the mail is coming
from, there's little point in wasting cycles with RBL checks unless you
want to use them to spot forged sender addresses.
The answers to these questions should help you figure out what you want
to do about users with infected machines and help you decide what to do
with the spam they're sending. It will also give us some idea of what to
suggest.
Martin
Re: SA on outgoing SMTP
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> Alexandre Chapellon wrote:
>> I am an ISP with over 50000 users (wich is not that big for an isp)
>> permannently connected.
>> I can hardly imagine to manage the poilicies of all my customer, and I
>> know they would really don't like it.
>> What if your ISP told you what you got to do, where to go and to forget
>> about your buggy OS your using for years?
On 16.02.10 13:57, Ted Mittelstaedt wrote:
> If your unwilling to block your dynamics from outbound SMTP then
> it is perfectly legitimate for the rest of the Internet to block
> you from sending them mail. This is equivalent to somebody being
> told that a home they own is being used by drug dealers to cook
> methamphetamines, and the homeowner saying "I can hardly imagine to
> manage the policies of all my renters, and I know they would really
> don't like it", then the community getting together and firebombing
> the home one night.
But even in such case you must be prepared that you
- will get reports about spam sent from their IP addresses
- will get blocked in blacklists like UCEPROTECT-L2 or UCEPROTECT-L3 that
block whole network if there's much spaming IPs in it.
- will have YOUR mail blocked because of the above.
(I'm not saying this is a good practice, but it will happen).
Blocking outgoing SMTP for any customers without mailserver is the easiest
and currently most effective way to stop this problem.
Note that I even do not like blocking customers from doing any kind of
stuff, but in the world where 90% machines have windows installed and 50% of
them is unmaintained, unprotected etc (does anyone know correct numbers)
there's nearly no other way to go.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.
Re: SA on outgoing SMTP
Posted by Ted Mittelstaedt <te...@ipinc.net>.
It is standard practice in the ISP industry to block outgoing port
25 nowadays on dynamically assigned addresses.
This is not a barrier to your customers using another mailserver
(google, gmail, etc.) because all of those businesses support
Auth-SMTP on the submission port 587. In fact, nowadays most
require it.
This is only a barrier to your customers who want to operate their
own mailservers.
Since those customers should have static IP addresses, if your
network has any reasonable organization you have a subnet set aside
for static IP addresses, one for dynamics, etc. You don't block the
statics when your doing this.
If your unwilling to block your dynamics from outbound SMTP then
it is perfectly legitimate for the rest of the Internet to block
you from sending them mail. This is equivalent to somebody being
told that a home they own is being used by drug dealers to cook
methamphetamines, and the homeowner saying "I can hardly imagine to
manage the policies of all my renters, and I know they would really
don't like it", then the community getting together and firebombing
the home one night.
Ted
Alexandre Chapellon wrote:
> I am an ISP with over 50000 users (wich is not that big for an isp)
> permannently connected.
> I can hardly imagine to manage the poilicies of all my customer, and I
> know they would really don't like it.
> What if your ISP told you what you got to do, where to go and to forget
> about your buggy OS your using for years?
>
> But mostly I agree, a clean network should be the basis.
>
> Le mardi 16 février 2010 à 12:40 -0800, Ted Mittelstaedt a écrit :
>
>> I know your not going to want to hear this because your looking
>> for a quick fix, but nothing substitutes for good network design.
>>
>> Your buggy customer network should enforce the following:
>>
>>
>> Direct SMTP transmission (port 25) is filtered so that only
>> machines designated as mailservers are allowed to send outbound
>> mail to port 25, everyone else must use the submission port 587 with
>> SMTP authentication to send mail to one of your mailservers, which
>> then relays this to the rest of the world.
>>
>>
>>
>> I know you don't have this now. But, you should be enforcing it
>> on new customers and you should adjust all of your self-help
>> documentation so that as customers discard PC's and set new ones
>> up, that they start using auth-SMTP on the submission port.
>>
>> It will take a few years. And for some time you will wonder why
>> your bothering since it will seem like your only doing all of the
>> extra work of maintaining auth-smtp for a minority of customer.
>>
>> But the day will come that you will realize the majority of your
>> customers are using smtp-auth. And every day after that the
>> number of clients sending mail directly to port 25 will continue
>> to dwindle and you will become more and more interested in just
>> chopping the minority off and letting them scream.
>>
>> Ted
>>
>> Alexandre Chapellon wrote:
>>> Hello the list,
>>>
>>> I have a quite buggy customer network, full of zombie PCs that spends
>>> all days sending spam and wasting the whole "reputation" of my networks.
>>> As a result it sometimes become quite hard to delivers queues for
>>> specific domains such as Yahoo!'s hosted ones. Indeed they have some
>>> temp fail (blacklist) mechanism that forbid my servers to send messages
>>> to them during hours.
>>> Taht's why I would like to setup some ougoing filtering to avoid sending
>>> too much spam through my mail relays. I think SA can help me in doing
>>> so, but I know too it's not really intented to work this way. I guess SA
>>> expects to work on MX hosts more than on smtp relays.
>>>
>>> My prerequisites are mainly:
>>> - STOP as much spam as possible at SMTP time (before queuing)
>>> - Have NO (or very few) false positives cause I could not manage
>>> telling thousands of users that they should *always_have_a_subject*,
>>> *shouldn't_write_the_subject_in_CAPS* or anything else.
>>>
>>> Further more I can't rely on RBL because a lot of my dyn IP address are
>>> regularily listed on different blacklist.
>>>
>>> Does anyone have already setup something like that and what specific
>>> config/tools/plugin could be usefull for me.
>>> If some one already done it.... does he/she have any statistics about
>>> the efficiency of this setup.
>>>
>>> Best regards.
>>>
>
>
>
Re: SA on outgoing SMTP
Posted by Frank Heydlauf <fh...@lf.net>.
Hi Alexandre,
On Tue, Feb 16, 2010 at 11:44:35AM -1000, Alexandre Chapellon wrote:
> I am an ISP with over 50000 users (wich is not that big for an isp)
> permannently connected.
FYI: similar scale here.
> I can hardly imagine to manage the poilicies of all my customer, and I know
> they would really don't like it.
On the other hand they will strongly dislike you if your net
is blacklisted and they are not longer able to send any
regular mail.
I think you'll lose more customers with mail-delays and
blacklist caused bounces than with limiting smtp outgoing.
And: If you enforce spamassassin-filters in your outgoing
smtp-traffic, this would be a new policy too!
> What if your ISP told you what you got to do, where to go and to forget about
> your buggy OS your using for years?
Even if you missed to tell your customers some rules - it's
common practice to have contracts that allow filtering or
disconnecting customers who abuse your infrastructure.
And even if you missed to put this in your contracts:
Not being a monopolist you should be able to cancel any
contract or limit the services if the customer threatens
your net and your business.
Customers are often not aware that they endangers
other customers and the ISPs infrastructure.
Tell them. Tell them about the expenses they cause
and about possible demand of recourses.
This works. Been there, done that.
Work on the proposal of Tom. You will not be able to
switch this in one day, that's fully obvious. But you
could on the one hand give new customers policies about
using smtp-auth and message submission only, on the
other hand filter outgoing port 25 of any user you
get complaints about. Allow these only connecting your
relayserver using message-submission with smtp-auth.
If you assign dynamic IPs, put all misbehaving customers
in a sperate IP-pool. Filter IPs in this pool.
If a customer wants to use an outside SMTP-Server,
allow this server (or any smtp-out) but tell the customer
you'll bill him for any of your expenses caused by
spam sent from his account - and of course tell him
you'll filter again any time his account is abused
again.
Spam sent from customers over your mailrelay is very
uncommon since bot-nets usually (so far) send without
using a relay to get a better throughput.
If spam is sent intensionally and repeatedly this is
a good reason to cancel the contract.
> But mostly I agree, a clean network should be the basis.
>
> Le mardi 16 fe'vrier 2010 a` 12:40 -0800, Ted Mittelstaedt a e'crit :
do not send fullquotes. Tnx.
--
Regards
Frank
Re: SA on outgoing SMTP
Posted by Alexandre Chapellon <al...@mana.pf>.
I am an ISP with over 50000 users (wich is not that big for an isp)
permannently connected.
I can hardly imagine to manage the poilicies of all my customer, and I
know they would really don't like it.
What if your ISP told you what you got to do, where to go and to forget
about your buggy OS your using for years?
But mostly I agree, a clean network should be the basis.
Le mardi 16 février 2010 à 12:40 -0800, Ted Mittelstaedt a écrit :
> I know your not going to want to hear this because your looking
> for a quick fix, but nothing substitutes for good network design.
>
> Your buggy customer network should enforce the following:
>
>
> Direct SMTP transmission (port 25) is filtered so that only
> machines designated as mailservers are allowed to send outbound
> mail to port 25, everyone else must use the submission port 587 with
> SMTP authentication to send mail to one of your mailservers, which
> then relays this to the rest of the world.
>
>
>
> I know you don't have this now. But, you should be enforcing it
> on new customers and you should adjust all of your self-help
> documentation so that as customers discard PC's and set new ones
> up, that they start using auth-SMTP on the submission port.
>
> It will take a few years. And for some time you will wonder why
> your bothering since it will seem like your only doing all of the
> extra work of maintaining auth-smtp for a minority of customer.
>
> But the day will come that you will realize the majority of your
> customers are using smtp-auth. And every day after that the
> number of clients sending mail directly to port 25 will continue
> to dwindle and you will become more and more interested in just
> chopping the minority off and letting them scream.
>
> Ted
>
> Alexandre Chapellon wrote:
> > Hello the list,
> >
> > I have a quite buggy customer network, full of zombie PCs that spends
> > all days sending spam and wasting the whole "reputation" of my networks.
> > As a result it sometimes become quite hard to delivers queues for
> > specific domains such as Yahoo!'s hosted ones. Indeed they have some
> > temp fail (blacklist) mechanism that forbid my servers to send messages
> > to them during hours.
> > Taht's why I would like to setup some ougoing filtering to avoid sending
> > too much spam through my mail relays. I think SA can help me in doing
> > so, but I know too it's not really intented to work this way. I guess SA
> > expects to work on MX hosts more than on smtp relays.
> >
> > My prerequisites are mainly:
> > - STOP as much spam as possible at SMTP time (before queuing)
> > - Have NO (or very few) false positives cause I could not manage
> > telling thousands of users that they should *always_have_a_subject*,
> > *shouldn't_write_the_subject_in_CAPS* or anything else.
> >
> > Further more I can't rely on RBL because a lot of my dyn IP address are
> > regularily listed on different blacklist.
> >
> > Does anyone have already setup something like that and what specific
> > config/tools/plugin could be usefull for me.
> > If some one already done it.... does he/she have any statistics about
> > the efficiency of this setup.
> >
> > Best regards.
> >
>
Re: SA on outgoing SMTP
Posted by Ted Mittelstaedt <te...@ipinc.net>.
I know your not going to want to hear this because your looking
for a quick fix, but nothing substitutes for good network design.
Your buggy customer network should enforce the following:
Direct SMTP transmission (port 25) is filtered so that only
machines designated as mailservers are allowed to send outbound
mail to port 25, everyone else must use the submission port 587 with
SMTP authentication to send mail to one of your mailservers, which
then relays this to the rest of the world.
I know you don't have this now. But, you should be enforcing it
on new customers and you should adjust all of your self-help
documentation so that as customers discard PC's and set new ones
up, that they start using auth-SMTP on the submission port.
It will take a few years. And for some time you will wonder why
your bothering since it will seem like your only doing all of the
extra work of maintaining auth-smtp for a minority of customer.
But the day will come that you will realize the majority of your
customers are using smtp-auth. And every day after that the
number of clients sending mail directly to port 25 will continue
to dwindle and you will become more and more interested in just
chopping the minority off and letting them scream.
Ted
Alexandre Chapellon wrote:
> Hello the list,
>
> I have a quite buggy customer network, full of zombie PCs that spends
> all days sending spam and wasting the whole "reputation" of my networks.
> As a result it sometimes become quite hard to delivers queues for
> specific domains such as Yahoo!'s hosted ones. Indeed they have some
> temp fail (blacklist) mechanism that forbid my servers to send messages
> to them during hours.
> Taht's why I would like to setup some ougoing filtering to avoid sending
> too much spam through my mail relays. I think SA can help me in doing
> so, but I know too it's not really intented to work this way. I guess SA
> expects to work on MX hosts more than on smtp relays.
>
> My prerequisites are mainly:
> - STOP as much spam as possible at SMTP time (before queuing)
> - Have NO (or very few) false positives cause I could not manage
> telling thousands of users that they should *always_have_a_subject*,
> *shouldn't_write_the_subject_in_CAPS* or anything else.
>
> Further more I can't rely on RBL because a lot of my dyn IP address are
> regularily listed on different blacklist.
>
> Does anyone have already setup something like that and what specific
> config/tools/plugin could be usefull for me.
> If some one already done it.... does he/she have any statistics about
> the efficiency of this setup.
>
> Best regards.
>