On 03/31/2011 08:36 PM, D G Teed wrote:
On Thu, Mar 31, 2011 at 1:41 PM, Stan Hoeppner <s...@hardwarefreak.com
<mailto:s...@hardwarefreak.com>> wrote:
D G Teed put forth on 3/31/2011 10:21 AM:
> I'd like some idea of what real world values would be useful, or
additional
> suggestions
> on how to make the performance less attractive to users of
compromised
> accounts.
When you find a reasonable and effective solution to the phishing
problem please share it with the rest of us.
The only sure fire solution I'm currently aware of is mass
executions of
stupid and/or ignorant people who have no business using a computer or
email. The obvious problem with this solution is it requires
exterminating well over half the human race, including many/most of my
family members. Not an appealing solution.
I think you misunderstood what I wrote. I listed actual postfix
variables, looking for input on practical values.
That depends way too much on your particular setup.
This isn't unreasonable
to expect. I've implemented restrictions on our webmail's SMTP
to the point that spammers login, send a few emails, find it doesn't work
for large number of recipients and then logout.
For such scenarios, even tighter restrictions (enforced by methods
external to postfix) would seem appropriate: simply record the number of
failed deliveries or spamassassin hits per web user, and disable the
account if this exceeds some threshold.
Rest assured that the big webmail providers use quite advanced methods
to detect hacked mail accounts that try to send spam - and they don't
depend solely on the MTA to provide this protection.
It works and I'm not dreaming.
Horde developers have also set up limits which greatly discourage
spamming. The only problem is we can't choke the number of
recipients on our general SMTP.
I was hoping for angles on rate limiting which normal users could live
with but would be useless for spam. In the couple of responses so
far, it seems it requires
something external - too bad it requires more layers - I hoped it was
within
the capabilities of anvil and such.
Rate limiting is certainly within anvil's capabilities, but you don't
want to constrain this on your external smtpd(8) listener.
Use submission instead.
Submission cleanly separates incoming mail from the Internet from
submissions by your own users, with no chance of the two types of
traffic mingling.
A separate smtpd(8) listener purely for webmail is also a good idea -
this doesn't even have to listen on the network.
All of these can have distinct restrictions placed on the traffic they
accept.
Actually, this conversation has me thinking, maybe we should have a
dedicated
SMTP just for external SMTP + TLS + SASL. That way I can do the same
recipient limit throttling and tell people not to expect it will work
for mass
mail outs.
Yes: it's called "submission"; it runs on port 587 by default and was
invented for this purpose.
You could also provide the people that need mass mailing with "special"
accounts that have less strict limits.
--
J.
