You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Aaron Bennett <ab...@clarku.edu> on 2010/12/17 17:28:32 UTC
preventing authenticated smtp users from triggering PBL
Hi,
I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows:
Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
for <RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
[98.216.185.77])
by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
for <RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
From: "USER NAME" <SE...@clarku.edu>
Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL?
Thanks,
Aaron
---
Aaron Bennett
Manager of Systems Administration
Clark University ITS
RE: preventing authenticated smtp users from triggering PBL
Posted by Gary Smith <ga...@holdstead.com>.
> I've got an issue where users off-campus who are doing authenticated
> SMTP/TLS from home networks are having their mail hit by the PBL. I
> have trusted_networks set to include the incoming relay, but still the
> PBL hits it as follows:
>
I mentioned in a direct email (as my blackberry won't make it to the list).
Use submission port (587 rfc) and only allow authentication over this port. Set your MTA not to do any type of checks with mail coming in from this one. On postfix, it's a simple config in the master.cf file.
This is secure enough and will accomplish what you want with very little headache. In fact, it's better because now you don't have to worry about any SA overhead for outgoing email. Everyone authenticates against this, and no worries about zombie machines, etc, because it will require a password either way.
Re: preventing authenticated smtp users from triggering PBL
Posted by Robert Schetterer <ro...@schetterer.org>.
Am 17.12.2010 20:50, schrieb Jason Bertoch:
> On 2010/12/17 2:48 PM, Robert Schetterer wrote:
>> forget trusted_networks use i.e spamass-milter
>> with spamassassin with option -I: skip (ignore) checks if sender is
>> authenticated
>
> Though I've not used spamass-milter, will this really work if the
> authentication server is not local?
>
should not matter , ( normally all auth processes with postfix are
based on sasl or dovecot etc ) , so it should only depend on a existing
and working authentication process what kind ever
i think internal this is checked over the milter code in postfix
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: preventing authenticated smtp users from triggering PBL
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/17 2:48 PM, Robert Schetterer wrote:
> forget trusted_networks use i.e spamass-milter
> with spamassassin with option -I: skip (ignore) checks if sender is
> authenticated
Though I've not used spamass-milter, will this really work if the
authentication server is not local?
--
/Jason
Re: preventing authenticated smtp users from triggering PBL
Posted by Robert Schetterer <ro...@schetterer.org>.
Am 17.12.2010 17:28, schrieb Aaron Bennett:
> Hi,
>
> I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows:
>
> Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
> by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
> for <RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
> [98.216.185.77])
> by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
> for <RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> From: "USER NAME" <SE...@clarku.edu>
>
> Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL?
>
> Thanks,
>
> Aaron
>
> ---
> Aaron Bennett
> Manager of Systems Administration
> Clark University ITS
>
forget trusted_networks use i.e spamass-milter
with spamassassin with option -I: skip (ignore) checks if sender is
authenticated
additional use clamav-milter with a few sanesecurity antispam sigs , its
fast enough to reject known spam from authed user without slowing down
deliver out
other chance, depending how you setted up spamassassin with postfix
read this
http://www200.pair.com/mecham/spam/bypassing.html
in some setups you can use simular configs
to bypass with spamassassin like bypass for amavis
specially
something like this
---snip
In main.cf:
smtpd_data_restrictions =
reject_unauth_pipelining
permit_sasl_authenticated
check_client_access regexp:/etc/postfix/add_auth_header.regexp
# In /etc/postfix/add_auth_header.regexp:
/^/ PREPEND X-SMTP-Auth: no
# In SpamAssassin's local.cf:
header __NO_SMTP_AUTH X-SMTP-Auth =~ /^no$/m
meta SMTP_AUTH !__NO_SMTP_AUTH
describe SMTP_AUTH Message sent using SMTP Authentication
tflags SMTP_AUTH nice
score SMTP_AUTH -10
I suggest you do not use X-SMTP-Auth literally. I would obscure this by
using a X-something-else header name of your choice, and if you have
more than one machine, I suggest using something different on each. In
order to prevent confusion (the header would end up getting written
again after the message was processed by amavisd-new), you should
override smtpd_data_restrictions on the amavisd-new reinjection port. In
master.cf add
-o smtpd_data_restrictions=
127.0.0.1:10025 inet n - n - - smtpd
-o content_filter=
-o smtpd_data_restrictions=
[other typical amavisd-new reinjection port overrides]
---snip
which is marking authed mail and bypass the spamassassin/amavis filter
afterwards
the recommended way is to let authed user use submission port
submission 587/tcp , without configured the filter for it in master.cf
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: preventing authenticated smtp users from triggering PBL
Posted by Eddie Hallahan <ed...@emcuk.com>.
Hi Aaron,
I know in our setup we just give trusted_networks a score of -120, that
way it usually doesn't matter if they kick off any PBL's etc on their
initial hop.
Regards
Eddie Hallahan
Enterprise Management Consulting
www.emcuk.com
Enterprise Management Consulting is a company registered in England and Wales with company number 3134554. VAT registration number is 681038440.
Aaron Bennett wrote:
> Hi,
>
> I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows:
>
> Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
> by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
> for <RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
> [98.216.185.77])
> by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
> for <RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> From: "USER NAME" <SE...@clarku.edu>
>
> Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL?
>
> Thanks,
>
> Aaron
>
> ---
> Aaron Bennett
> Manager of Systems Administration
> Clark University ITS
>
>
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
I've tusseled with this and eventually I gave up and setup a cheap PC
with FreeBSD that does nothing other than serve authenticated SMTP for
customers. Obviously it does not run spamassassin. It relays all mail
(inbound and outbound) to the main server.
The one thing I would advise if you do this is to apply a limit to
the maximum number of message recipients and if you can, rate-limit the
mail. Sooner or later a spammer will discover one of your user's
passwords and they will commence relaying through the server. Also,
I would STRONGLY advise that you block inbound port 25 on this server
and only permit inbound traffic on port 587, the submission port.
Ted
On 12/17/2010 8:28 AM, Aaron Bennett wrote:
> Hi,
>
> I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows:
>
> Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
> by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
> for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
> [98.216.185.77])
> by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
> for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> From: "USER NAME"<SE...@clarku.edu>
>
> Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL?
>
> Thanks,
>
> Aaron
>
> ---
> Aaron Bennett
> Manager of Systems Administration
> Clark University ITS
>
>
Re: preventing authenticated smtp users from triggering PBL
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/17 11:46 AM, Aaron Bennett wrote:
>
>> -----Original Message-----
>>
>> Based on the headers you included, there's nothing indicating the sender
>> was authenticated. Are you using the following in postfix?
>>
>> smtpd_sasl_authenticated_header yes
>
>
> No, I'm not -- that's a good idea. If I turn that on, can I write a rule based on it, or will SA pick up on it automatically?
>
SA is supposed to pick up on it automatically.
--
/Jason
RE: preventing authenticated smtp users from triggering PBL
Posted by Aaron Bennett <ab...@clarku.edu>.
> -----Original Message-----
>
> Based on the headers you included, there's nothing indicating the sender
> was authenticated. Are you using the following in postfix?
>
> smtpd_sasl_authenticated_header yes
No, I'm not -- that's a good idea. If I turn that on, can I write a rule based on it, or will SA pick up on it automatically?
Thanks,
Aaron
RE: preventing authenticated smtp users from triggering PBL
Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> SA also avails the msa_networks setting to allow a node to act both as
> a MX and a MUA, making a message look like "internally sourced" iff the
> node says it is from an authenticated source.
Of course, I meant:
SA also avails of the msa_networks setting to allow a node to act both as a
MTA and a MSA, making a message look like "internally sourced" iff that node
says it is from an authenticated source.
I always get into confusion with these tricky acronyms...
Giampaolo
RE: preventing authenticated smtp users from triggering PBL
Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> From: Ted Mittelstaedt [mailto:tedm@ipinc.net]
>
> And what prevents a spammer from forging this into a header and
> bypassing SA? Just askin.
>
> Ted
The fact that the authenticating server forwarding the request is trusted
and/or internal network.
SA doesn't look at any auth token outside of the trusted ring. A spammer can
obviously add a fake received: header, but it would be left out of the
trusted ring and thereby not considered by SA.
In example. example@example.com is your trusted, border MSA.
This is really authenticated, of course:
Received: from imauser (host246-74-dynamic.49-82-r.retail.telecomitalia.it
[82.49.74.246])
by msa.example.com (Postfix) with ESMTPA id 4582D39D066
for <ex...@example.com>; Fri, 17 Dec 2010 17:48:01 +0100 (CET)
This is not:
Received: from imaspammer
(host246-74-dynamic.49-82-r.retail.telecomitalia.it [82.49.74.246])
by msa.example.com (Postfix) with ESMTPA id 4582D39D066
for <ex...@example.com>; Fri, 17 Dec 2010 17:48:01 +0100 (CET)
Received: from msa.example.com
(host246-74-dynamic.49-82-r.retail.telecomitalia.it [82.49.74.246])
by msa.example.com (Postfix) with ESMTP id 4582D39D066
for <ex...@example.com>; Fri, 17 Dec 2010 17:48:01 +0100 (CET)
See? The first Received: is the forged one and looks a lot like the second
one, which is the true one. SA would stop looking for auth keywords (ESMTPA,
in this example) right at the second line and would not take the first into
account...
SA also avails the msa_networks setting to allow a node to act both as a MX
and a MUA, making a message look like "internally sourced" iff the node says
it is from an authenticated source.
Giampaolo
Re: preventing authenticated smtp users from triggering PBL
Posted by Patrick Ben Koetter <p...@state-of-mind.de>.
* Ted Mittelstaedt <te...@ipinc.net>:
> On 12/17/2010 8:41 AM, Jason Bertoch wrote:
> >On 2010/12/17 11:28 AM, Aaron Bennett wrote:
> >>I've got an issue where users off-campus who are doing authenticated
> >>SMTP/TLS from home networks are having their mail hit by the PBL. I
> >>have trusted_networks set to include the incoming relay, but still the
> >>PBL hits it as follows:
> >>
> >>Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
> >>by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
> >>for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> >>Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
> >>[98.216.185.77])
> >>by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
> >>for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> >>From: "USER NAME"<SE...@clarku.edu>
> >>
> >>Despite that internal_networks and trusted_networks are set to
> >>140.232.0.0/16, the message still triggers the PBL rule. Given that I
> >>know that (unless there's a trojaned machine or whatever) I must trust
> >>email that comes in over authenticated SMTP/TLS through the 'cmail'
> >>host, how can I prevent it from hitting the PBL?
> >
The examples you provided above only tell ESMTP was used. This make me think
you are either using a very ancient version of Postfix or the Received: headers
stem from a sender who did not SMTP AUTH, because Postfix prints ESMTPSA
(S=secure, A=authenticated) when TLS and SMTP AUTH have been used in the SMTP
session.
> >Based on the headers you included, there's nothing indicating the sender
> >was authenticated. Are you using the following in postfix?
> >
> >smtpd_sasl_authenticated_header yes
>
> And what prevents a spammer from forging this into a header and
> bypassing SA? Just askin.
Anyone can forge this, but you don't need to fall for it.
You could, for example, only let users send messages from your servers if they
use the submission port (tcp/587). On this port SMTP AUTH is a must to send a
message and smtpd_sasl_authenticated_header may be trusted safely (unless
someones credentials have been stolen and the spammer uses that identity).
At the same time you disable SMTP AUTH on port 25 and kill any header that
claims to be from your server using ESMTPA or ESMTPSA.
You could, for example, place a special header check next to your regular port
25 smtp service in master.cf. The header check rule matches on your server
name and the string ESMTP[A|SA] and results in IGNORE (see: man 5
header_checks):
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
-o header_checks=pcre:/etc/postfix/kill_forged_headers
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_authenticated_header=yes
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
in /etc/postfix/kill_forged_headers:
/^by\hexample.org\h\(Postfix\)\hwith\hESMTP[A|SA]/ IGNORE
p@rick
--
state of mind
Digitale Kommunikation
http://www.state-of-mind.de
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Re: preventing authenticated smtp users from triggering PBL
Posted by Benny Pedersen <me...@junc.org>.
On fre 17 dec 2010 18:36:25 CET, Ted Mittelstaedt wrote
> But, go ahead, do it your way. If your a small site you might
> even be OK for long enough to forget this advice. But sooner
> or later your going to get cracked into and you will wish you
> had separated the servers.
clamav stops most of this shit from spammers, no seperated servers
needed here, i see it as you say add more mx records on dns to help
stop spaming, but as long users are plain stupid to reset passwords
then thay loose all secureity
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: preventing authenticated smtp users from triggering PBL
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 17 Dec 2010 11:24:51 -0800
Ted Mittelstaedt <te...@ipinc.net> wrote:
> It is possible this is because I use sa-milter.
If you want to make complex policy decisions, you might want to use
something like MIMEDefang (note: I'm the author. :))
It lets you encode your mail processing logic in Perl, so you can
avoid SA if mail meets certain criteria.
MIMEDefang isn't always appropriate, but it's the first tool that
comes to mind if you need complex or flexible filtering policy.
http://www.mimedefang.org/
Regards,
David.
Re: preventing authenticated smtp users from triggering PBL
Posted by Bowie Bailey <Bo...@BUC.com>.
On 12/17/2010 2:24 PM, Ted Mittelstaedt wrote:
>
>
> Exactly my point. The problem I have had with SA as I said in my
> original response is that even if you use authenticated SMTP that
> setting the auth flag in the received header simply didn't work.
> Even when it is there, SA still filtered. If you say that setting
> the flag only makes SA skip the RBL checks then I believe you,
> but what is the point, the RBL checks aren't the issue. The
> filtering is the issue.
If SA can see that the message was authenticated, it will extend its
trust network to include the machine that authenticated. This mainly
affects things like blacklist lookups. Other than that, it will have no
effect.
SA will scan everything you give it regardless of the source. If you do
not want certain messages to be scanned, you need to find a way to
prevent them from being sent to SA. Perhaps there is a setting in
sa-milter for this.
--
Bowie
Re: preventing authenticated smtp users from triggering PBL
Posted by Michael Scheidell <mi...@secnap.com>.
On 12/17/10 11:04 PM, Ted Mittelstaedt wrote:
>
> It's shit-for-brains young girl administrative assistants at companies
> who are our customers who apparently have too much time on their hands.
Don't hold back,.. how do you REALLY feel about outlook stationary?
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
>*| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best in Email Security,2010: Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 11:57 AM, Giampaolo Tomassoni wrote:
>> On 12/17/2010 10:15 AM, Kris Deugau wrote:
>>> Ted Mittelstaedt wrote:
>>>> I know that, Sendmail adds the same flag when setup for auth SMTP.
>> The
>>>> problem is that SA will see this and assume the mail is safe.
>>>
>>> Noooo.... if your trust path is set correctly, then SA won't run
>> tests
>>> like eg PBL (IP blocks designated by the nominal owner as "not
>> allowed
>>> to send SMTP traffic to world+dog"). It does NOT mean SA treats the
>> mail
>>> as "safe".
>>>
>>
>> That doesn't help us you see because we have users who send mail that
>> is constructed in such a way as it will trigger the other SA tests,
>> yet they insist on being allowed to send it.
>
> Is it spam, maybe?
>
It's shit-for-brains young girl administrative assistants at companies
who are our customers who apparently have too much time on their hands.
When you see e-mails using fonts, blue lettering on a yellow-orange
background that contains a jpg of a sunset with a big-old smiley in
the sun, liberally laced with capitalized words, the "blink" tag, and
a half dozen fluff URL's they apparently found during the mornings
surfing of pictures of kittens clawing stuffed toys, copied to at
least 50 of their other shit-for-brains friends at other companies,
it makes you wonder how these companies make any money at all.
I guess these creatures must serve a decorative function at the
reception desk. Certainly they can't be trusted to answer the phone!
> Note you can craft a rule such that authenticated in-bound mail may get some
> negative points, such that even spam-looking messages may pass.
>
But then I have to be forever modifying it when the next customer hires
another one of the airheads.
>
>>>> In the versions of SA I have used, SA will assume the mail is safe
>>>> no matter what Received line in the header has the auth indicator
>>>> set. They may have fixed that in the most recent SA but I don't
>>>> believe so,
>>>
>>> *scratch head* I've never had problems with mistaken RBL hits
>>
>> It's not the RBL hits that are the problem.
>
> Uhu? Wasn't this thread about this?
>
I took the OP's post to mean that the RBL hit was just the proverbial
canary in the coal mine, in other words he's seeing the RBL hits
because those are the ones that go over the threshold and get the
message blocked, but that ultimately he didn't want ANY filtering on an
authenticated SMTP mail.
But perhaps he does just want SA doing filtering with the exception of
the RBL checks, on incoming auth-smtp. That sounds odd to me, but
whatever floats your boat I guess.
>
>>> as the OP
>>> is asking about *if* I've got my *_networks set correctly. Earlier
>> this
>>> year I discovered an edge case with our "accelerated dialup" service
>> and
>>> had to make some adjustments to the trust path to include the
>>> accelerator host as an MSA - but previous to that the setup had been
>>> working correctly.
>>>
>>>> and even if they did then what if SA is running on a
>>>> prefilter server in front of an Exchange server for example?
>>>
>>> I have no idea what scenario you're referring to here - inbound mail?
>>> The OP is asking about outbound mail; and so far as your own
>> filtering
>>> is concerned, (especially) if you're an ISP your spam filter really
>>> shouldn't penalize customers who send mail directly through the SMTP
>>> server you provide, whether that's separate from your MX(es) or not.
>>>
>>
>> Exactly my point. The problem I have had with SA as I said in my
>> original response is that even if you use authenticated SMTP that
>> setting the auth flag in the received header simply didn't work.
>> Even when it is there, SA still filtered. If you say that setting
>> the flag only makes SA skip the RBL checks then I believe you,
>> but what is the point, the RBL checks aren't the issue. The
>> filtering is the issue.
>>
>> It is possible this is because I use sa-milter. It is possible
>> this is because I have an older SA version that's been fixed now.
>
> So, it had issues with PBL too?
>
>
>> There's many possibilities. But, whatever the problem, the
>> easy fix was using a separate machine for auth-smtp and not
>> running SA on it. It was
>> only a few years later after doing this when I stated seeing the
>> spammers cracking auth-smtp passwords, that I realized how many
>> OTHER benefits to using a separate auth-smtp server that there are.
>
> In example, having all that spam from cracked accounts to pass without
> earning any score...
>
> Isn't this exactly the benefit on gets SA-filtering also authenticated
> messages?
>
> Also, most SA spawners (like amavis-new, in example) may even drop and/or
> send you alerts when a message is earning too many spam points.
>
> Amavis-new also has banks, which lets you tune the handling of a suspicious
> message based on the its direction (inbound or submitted for outbound).
>
Those are good points and touch on what I would call different
approaches to e-mail on the Internet.
These days, with the free mail providers, hotmail, gmail, etc. quite a
lot of people have gotten used to the notion that e-mailboxes should be
free.
Well, you know how it is with something that you get for free - you
get what is given to you and you do it their way and shut up about it.
So, if gmail wants to filter mail your sending from your mail client
for them to relay to the world, if they decide that a particular message
you send to them is spam, using whatever arbitrary rule they want, if
you don't like it, then as they say, Talk To The Hand.
With us all our customers pay for mailboxes. Yes we have a number of
customers who don't care that much about mail and
don't pay us for a box and just get connectivity and get their boxes
from gmail or whatever other free provider they want.
But the ones that do, pay us so that if there's a problem they can pick
up the phone and get someone who will fix it, even if that means that
that someone has to spend 20 minutes digging though the logs to discover
that the problem isn't even us or them, it's some recipient they are
sending to that has a cocked up e-mail program that cannot digest that
80MB attachment they sent out.
In exchange they naturally want to have mail done "their" way not
"our" way because, after all, they are paying us. And "their" way
means that if they want to create an e-mail using fonts, blue lettering
on a yellow-orange background that contains a jpg of a sunset with a
big-old smiley in the sun, liberally laced with capitalized words, the
"blink" tag, and a half dozen fluff URL's they apparently found during
the mornings surfing of pictures of kittens clawing stuffed toys, copied
to at least 50 of their other shit-for-brains friends at other
companies, then by God they are gonna be able to do so and send it
out without being blocked, dag nabbit!!
It's just different viewpoints on what is best. In our case, we have
to be like the cops and go after the spammers AFTER they start spamming,
we cannot be proactive and block them before they even start, because
we cannot afford any false positives. Any of our customers who can
tolerate a few FP's have already discovered they can pay less elsewhere
and aren't on our service.
Ted
RE: preventing authenticated smtp users from triggering PBL
Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> On 12/17/2010 10:15 AM, Kris Deugau wrote:
> > Ted Mittelstaedt wrote:
> >> I know that, Sendmail adds the same flag when setup for auth SMTP.
> The
> >> problem is that SA will see this and assume the mail is safe.
> >
> > Noooo.... if your trust path is set correctly, then SA won't run
> tests
> > like eg PBL (IP blocks designated by the nominal owner as "not
> allowed
> > to send SMTP traffic to world+dog"). It does NOT mean SA treats the
> mail
> > as "safe".
> >
>
> That doesn't help us you see because we have users who send mail that
> is constructed in such a way as it will trigger the other SA tests,
> yet they insist on being allowed to send it.
Is it spam, maybe?
Note you can craft a rule such that authenticated in-bound mail may get some
negative points, such that even spam-looking messages may pass.
> >> In the versions of SA I have used, SA will assume the mail is safe
> >> no matter what Received line in the header has the auth indicator
> >> set. They may have fixed that in the most recent SA but I don't
> >> believe so,
> >
> > *scratch head* I've never had problems with mistaken RBL hits
>
> It's not the RBL hits that are the problem.
Uhu? Wasn't this thread about this?
> > as the OP
> > is asking about *if* I've got my *_networks set correctly. Earlier
> this
> > year I discovered an edge case with our "accelerated dialup" service
> and
> > had to make some adjustments to the trust path to include the
> > accelerator host as an MSA - but previous to that the setup had been
> > working correctly.
> >
> >> and even if they did then what if SA is running on a
> >> prefilter server in front of an Exchange server for example?
> >
> > I have no idea what scenario you're referring to here - inbound mail?
> > The OP is asking about outbound mail; and so far as your own
> filtering
> > is concerned, (especially) if you're an ISP your spam filter really
> > shouldn't penalize customers who send mail directly through the SMTP
> > server you provide, whether that's separate from your MX(es) or not.
> >
>
> Exactly my point. The problem I have had with SA as I said in my
> original response is that even if you use authenticated SMTP that
> setting the auth flag in the received header simply didn't work.
> Even when it is there, SA still filtered. If you say that setting
> the flag only makes SA skip the RBL checks then I believe you,
> but what is the point, the RBL checks aren't the issue. The
> filtering is the issue.
>
> It is possible this is because I use sa-milter. It is possible
> this is because I have an older SA version that's been fixed now.
So, it had issues with PBL too?
> There's many possibilities. But, whatever the problem, the
> easy fix was using a separate machine for auth-smtp and not
> running SA on it. It was
> only a few years later after doing this when I stated seeing the
> spammers cracking auth-smtp passwords, that I realized how many
> OTHER benefits to using a separate auth-smtp server that there are.
In example, having all that spam from cracked accounts to pass without
earning any score...
Isn't this exactly the benefit on gets SA-filtering also authenticated
messages?
Also, most SA spawners (like amavis-new, in example) may even drop and/or
send you alerts when a message is earning too many spam points.
Amavis-new also has banks, which lets you tune the handling of a suspicious
message based on the its direction (inbound or submitted for outbound).
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 10:15 AM, Kris Deugau wrote:
> Ted Mittelstaedt wrote:
>> I know that, Sendmail adds the same flag when setup for auth SMTP. The
>> problem is that SA will see this and assume the mail is safe.
>
> Noooo.... if your trust path is set correctly, then SA won't run tests
> like eg PBL (IP blocks designated by the nominal owner as "not allowed
> to send SMTP traffic to world+dog"). It does NOT mean SA treats the mail
> as "safe".
>
That doesn't help us you see because we have users who send mail that
is constructed in such a way as it will trigger the other SA tests,
yet they insist on being allowed to send it.
>> In the versions of SA I have used, SA will assume the mail is safe
>> no matter what Received line in the header has the auth indicator
>> set. They may have fixed that in the most recent SA but I don't
>> believe so,
>
> *scratch head* I've never had problems with mistaken RBL hits
It's not the RBL hits that are the problem.
> as the OP
> is asking about *if* I've got my *_networks set correctly. Earlier this
> year I discovered an edge case with our "accelerated dialup" service and
> had to make some adjustments to the trust path to include the
> accelerator host as an MSA - but previous to that the setup had been
> working correctly.
>
>> and even if they did then what if SA is running on a
>> prefilter server in front of an Exchange server for example?
>
> I have no idea what scenario you're referring to here - inbound mail?
> The OP is asking about outbound mail; and so far as your own filtering
> is concerned, (especially) if you're an ISP your spam filter really
> shouldn't penalize customers who send mail directly through the SMTP
> server you provide, whether that's separate from your MX(es) or not.
>
Exactly my point. The problem I have had with SA as I said in my
original response is that even if you use authenticated SMTP that
setting the auth flag in the received header simply didn't work.
Even when it is there, SA still filtered. If you say that setting
the flag only makes SA skip the RBL checks then I believe you,
but what is the point, the RBL checks aren't the issue. The
filtering is the issue.
It is possible this is because I use sa-milter. It is possible
this is because I have an older SA version that's been fixed now.
There's many possibilities. But, whatever the problem, the
easy fix was using a separate machine for auth-smtp and not
running SA on it. It was
only a few years later after doing this when I stated seeing the
spammers cracking auth-smtp passwords, that I realized how many
OTHER benefits to using a separate auth-smtp server that there are.
>> And you still have the problem of if a spammer's custom-written
>> virus has determined a user password. The spammers are now able
>> to do this with some of their hijack tools. And there are also a
>> LOT of phishing spams now that we see from time to time that tell
>> users that their e-mail password needs to be reset and to go to
>> such and such a webpage and change it, etc.
>
> I'm not sure where you're going with this, but this scenario will be a
> problem with SMTP AUTH no matter how that info is passed to SA. Unless
> you can guarantee real control over end-user systems, you *will* have to
> deal with this somehow. I'll leave it at that since the original
> question was about preventing PBL hits on authenticated users.
>
And my original answer was don't run SA on the authenticated users
by the solution of using a separate auth-smtp machine.
>> But, go ahead, do it your way. If your a small site you might
>> even be OK for long enough to forget this advice. But sooner
>> or later your going to get cracked into and you will wish you
>> had separated the servers.
>
> The ISP I work for currently has 6 machines handling customer-facing
> mail services - two physical machines for MX, two for outbound SMTP and
> two running SA and Clam.
>
> I've worked with a number of single-machine and partial-split
> configurations on a smaller scale, but I don't recall any special
> challenges tracking down a cracked account. TBH the only "problem" I
> recall was the size of the logfiles relative to available CPU power to
> search them.
>
Dealing with the logfiles is an issue but more of an issue is when
the spammers are using a hijacked system that isn't on a very fast
line or isn't sending traffic very fast. In those cases one of
my tricks is to temporarily change the server to queueing-only,
then let the server alone for 20 minutes. Then it is really easy
to identify the spam in the mail queue because there is so much
of it relative to the legitimate mail.
Spammers have gotten very tricky and nowadays they parallelize spamruns.
What they will do is your compromised machine will not just have a
single message that it hammers out to 10,000 victims, instead it has
100 different messages that are hammered out to 100 different victims.
Presumably they have 100 other machines across the Internet that are
also cracked and are doing the same thing that are working on alternate
chunks of the victim list.
When I have to track these things now I am increasingly finding
the queue filled up with 5-10 groups of spams that are entirely
different messages. I might have 1000 messages in there but only
100 of them have the same payload. (of course, each group is a
variation on the same theme) It makes it harder to find
the commonality. Of course, once you find the commonality then
it is a simple matter to identify the sending IP address, and then
use your other logs to see what userID authenticated in with that
address. The spammers are doing this because it reduces commonality
in the mail log, and makes it a lot harder to isolate the sending
IP address.
Another thing they do is they used to throw 30-40 senders at you,
all using the same compromised credential. But now it's usually less
than 10. I had one 3 weeks ago that used a total of 6 senders.
The spammers are probably doing that because they find when they
use lots of machines that the admin of the relay host reports all
their machines and then the spammers suddenly lose a good chunk of
their DDoS network. By reducing the number of transmitters on each
mule, it limits the liability should they happen to use a mule
with a clueful sysadmin.
Ted
> -kgd
Re: preventing authenticated smtp users from triggering PBL
Posted by Kris Deugau <kd...@vianet.ca>.
Ted Mittelstaedt wrote:
> I know that, Sendmail adds the same flag when setup for auth SMTP. The
> problem is that SA will see this and assume the mail is safe.
Noooo.... if your trust path is set correctly, then SA won't run tests
like eg PBL (IP blocks designated by the nominal owner as "not allowed
to send SMTP traffic to world+dog"). It does NOT mean SA treats the
mail as "safe".
> In the versions of SA I have used, SA will assume the mail is safe
> no matter what Received line in the header has the auth indicator
> set. They may have fixed that in the most recent SA but I don't
> believe so,
*scratch head* I've never had problems with mistaken RBL hits as the OP
is asking about *if* I've got my *_networks set correctly. Earlier this
year I discovered an edge case with our "accelerated dialup" service and
had to make some adjustments to the trust path to include the
accelerator host as an MSA - but previous to that the setup had been
working correctly.
> and even if they did then what if SA is running on a
> prefilter server in front of an Exchange server for example?
I have no idea what scenario you're referring to here - inbound mail?
The OP is asking about outbound mail; and so far as your own filtering
is concerned, (especially) if you're an ISP your spam filter really
shouldn't penalize customers who send mail directly through the SMTP
server you provide, whether that's separate from your MX(es) or not.
> And you still have the problem of if a spammer's custom-written
> virus has determined a user password. The spammers are now able
> to do this with some of their hijack tools. And there are also a
> LOT of phishing spams now that we see from time to time that tell
> users that their e-mail password needs to be reset and to go to
> such and such a webpage and change it, etc.
I'm not sure where you're going with this, but this scenario will be a
problem with SMTP AUTH no matter how that info is passed to SA. Unless
you can guarantee real control over end-user systems, you *will* have to
deal with this somehow. I'll leave it at that since the original
question was about preventing PBL hits on authenticated users.
> But, go ahead, do it your way. If your a small site you might
> even be OK for long enough to forget this advice. But sooner
> or later your going to get cracked into and you will wish you
> had separated the servers.
The ISP I work for currently has 6 machines handling customer-facing
mail services - two physical machines for MX, two for outbound SMTP and
two running SA and Clam.
I've worked with a number of single-machine and partial-split
configurations on a smaller scale, but I don't recall any special
challenges tracking down a cracked account. TBH the only "problem" I
recall was the size of the logfiles relative to available CPU power to
search them.
-kgd
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 9:12 AM, Kris Deugau wrote:
> Ted Mittelstaedt wrote:
>> On 12/17/2010 8:41 AM, Jason Bertoch wrote:
>>> Based on the headers you included, there's nothing indicating the sender
>>> was authenticated. Are you using the following in postfix?
>>>
>>> smtpd_sasl_authenticated_header yes
>>>
>>
>> And what prevents a spammer from forging this into a header and
>> bypassing SA? Just askin.
>
> It's not a separate header; it's a switch to indicate SMTP AUTH in the
> Received: header that Postfix adds.
>
> -kgd
I know that, Sendmail adds the same flag when setup for auth SMTP. The
problem is that SA will see this and assume the mail is safe. This is
the fundamental problem with passing trust indicators in the headers.
In the versions of SA I have used, SA will assume the mail is safe
no matter what Received line in the header has the auth indicator
set. They may have fixed that in the most recent SA but I don't
believe so, and even if they did then what if SA is running on a
prefilter server in front of an Exchange server for example?
And you still have the problem of if a spammer's custom-written
virus has determined a user password. The spammers are now able
to do this with some of their hijack tools. And there are also a
LOT of phishing spams now that we see from time to time that tell
users that their e-mail password needs to be reset and to go to
such and such a webpage and change it, etc.
A couple times a month I'm changing user passwords who have
fallen for these phishes. Sometimes it is mere minutes after
the user has pasted their existing e-mail password into one of
these phish sites that the spammers start relaying spam though
the mailserver. However mostly, the typical MO is the spammers
wait until Friday night at 9pm local time and then start up the
spamming.
This is why a separate auth SMTP server is a very useful thing to
have. It is much easier to identify a spam injector when the
mailserver is only handling authenticated SMTP and determine what
compromised userID they are using. And you can apply
rate-limits on an authenticated-SMTP server that you cannot get
away with on the main mailserver.
But, go ahead, do it your way. If your a small site you might
even be OK for long enough to forget this advice. But sooner
or later your going to get cracked into and you will wish you
had separated the servers.
Ted
Re: preventing authenticated smtp users from triggering PBL
Posted by Kris Deugau <kd...@vianet.ca>.
Ted Mittelstaedt wrote:
> On 12/17/2010 8:41 AM, Jason Bertoch wrote:
>> Based on the headers you included, there's nothing indicating the sender
>> was authenticated. Are you using the following in postfix?
>>
>> smtpd_sasl_authenticated_header yes
>>
>
> And what prevents a spammer from forging this into a header and
> bypassing SA? Just askin.
It's not a separate header; it's a switch to indicate SMTP AUTH in the
Received: header that Postfix adds.
-kgd
Re: preventing authenticated smtp users from triggering PBL
Posted by Benny Pedersen <me...@junc.org>.
On fre 17 dec 2010 17:47:26 CET, Ted Mittelstaedt wrote
>> smtpd_sasl_authenticated_header yes
> And what prevents a spammer from forging this into a header and
> bypassing SA? Just askin.
clever :-)
this is just informative header, not one that disable sasl in postfix
sender can add this header self yes, but postfix still ask for password
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 9:32 AM, Benny Pedersen wrote:
> On fre 17 dec 2010 18:19:55 CET, Ted Mittelstaedt wrote
>> The whole point of auth smtp is to come from UN-trusted networks.
>
> will not agre on that one, if you require auth it must check all ip even
> localhost
>
I don't mean to say that just because auth is required from
untrusted networks that it's not a good idea to use it on trusted
ones.
it's actually also a very good idea to block off port 25 from your
mail clients even the ones ON trusted networks.
In fact a good case can be made for ignoring the trusted networks
mechanism in SA entirely and spamfiltering everything, even the
stuff coming from your own users.
unfortunately, while you can do that in a corporation it is
difficult for a commercial ISP to do it to users that are
paying them for mail. Users are hypocritical in this way,
they want to send e-mail loaded up with very spam-like
constructions (html, blank subject lines, etc.) but they don't
want to receive it. ;-)
> or yes, i see any ip as untrusted if user do not pass sasl auth
>
> firefox is olso a safer password browser if you store login passwords in
> it and forget to enable master password, but some see it as a feature, i
> see it as a bug
>
I regard almost the entire concept of storing passwords for interactive
programs as utterly defeating the purpose of having passwords in the
first place, but I recognize this isn't universally accepted.
Ted
Re: preventing authenticated smtp users from triggering PBL
Posted by Benny Pedersen <me...@junc.org>.
On fre 17 dec 2010 18:19:55 CET, Ted Mittelstaedt wrote
> The whole point of auth smtp is to come from UN-trusted networks.
will not agre on that one, if you require auth it must check all ip
even localhost
or yes, i see any ip as untrusted if user do not pass sasl auth
firefox is olso a safer password browser if you store login passwords
in it and forget to enable master password, but some see it as a
feature, i see it as a bug
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: preventing authenticated smtp users from triggering PBL
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> On 2010/12/17 11:47 AM, Ted Mittelstaedt wrote:
>>> And what prevents a spammer from forging this into a header and
>>> bypassing SA? Just askin.
> On 12/17/2010 8:51 AM, Jason Bertoch wrote:
>> Without checking, I'd guess that matching an authentication header with
>> an address in trusted_networks would be sufficient.
On 17.12.10 09:19, Ted Mittelstaedt wrote:
> why are you using authenticated SMTP from trusted networks?
> The whole point of auth smtp is to come from UN-trusted networks.
Not exactly. The point of auth smtp is not to accept mail from anyone
without authentication, even if ip-based for some hosts.
>> If your
>> authentication server is relaying for spammers, you've got an entirely
>> different problem.
> No, not really. You as an administrator cannot control what your users
> do and if your users save their authenticated SMTP passwords into their
> e-mail clients then later allow their machines to be cracked, then the
> crackers get the auth password and away they go.
I think this depends on order of mail headers. If authenticating server
before the received header, it is surely trusted.
Otherwise you are right and we don't know, if it wasn't the spammer who
started with fake authentication header.
The best is, of course, to put the authentication data to the Received:
header so we don't have to take care of the header order.
--
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.
Silvester Stallone: Father of the RISC concept.
Re: preventing authenticated smtp users from triggering PBL
Posted by RW <rw...@googlemail.com>.
On Fri, 17 Dec 2010 10:11:11 -0800
Ted Mittelstaedt <te...@ipinc.net> wrote:
> On 12/17/2010 9:28 AM, Jason Bertoch wrote:
> > In the OP's case, his authenticating server is separate from his SA
> > server. In any case, the server indicating authentication
> > (localhost or otherwise) should be a trusted server, else you don't
> > trust the authentication.
> >
>
> auth-smtp is only a speedbump to the spammers, it blocks the
> dumb ones. A sophisticated spammer can hijack a machine and use
> it's authenticated SMTP connection to it's mailserver to send
> spam. I never trust the authentication.
The main reason for SA checking authentication is to turn-off MX
specific tests such as PBL, for that reason you have to be able to trust
the authentication. That's not the same as trusting the sender.
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 9:28 AM, Jason Bertoch wrote:
> On 2010/12/17 12:19 PM, Ted Mittelstaedt wrote:
>> why are you using authenticated SMTP from trusted networks?
>>
>> The whole point of auth smtp is to come from UN-trusted networks.
>>
>
> In the OP's case, his authenticating server is separate from his SA
> server. In any case, the server indicating authentication (localhost or
> otherwise) should be a trusted server, else you don't trust the
> authentication.
>
auth-smtp is only a speedbump to the spammers, it blocks the
dumb ones. A sophisticated spammer can hijack a machine and use
it's authenticated SMTP connection to it's mailserver to send
spam. I never trust the authentication.
>>> If your
>>> authentication server is relaying for spammers, you've got an entirely
>>> different problem.
>>>
>>
>> No, not really. You as an administrator cannot control what your users
>> do and if your users save their authenticated SMTP passwords into their
>> e-mail clients then later allow their machines to be cracked, then the
>> crackers get the auth password and away they go.
>
> As I said, that is a different problem. Feel free not to use smtp-auth,
> or require VPN first, or whatever makes you happy.
>
Depends on what your users need. You apparently have savvy ones so
you have gotten soft. I have ignorant ones so I trust nobody.
Ted
Re: preventing authenticated smtp users from triggering PBL
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/17 12:19 PM, Ted Mittelstaedt wrote:
> why are you using authenticated SMTP from trusted networks?
>
> The whole point of auth smtp is to come from UN-trusted networks.
>
In the OP's case, his authenticating server is separate from his SA
server. In any case, the server indicating authentication (localhost or
otherwise) should be a trusted server, else you don't trust the
authentication.
>> If your
>> authentication server is relaying for spammers, you've got an entirely
>> different problem.
>>
>
> No, not really. You as an administrator cannot control what your users
> do and if your users save their authenticated SMTP passwords into their
> e-mail clients then later allow their machines to be cracked, then the
> crackers get the auth password and away they go.
As I said, that is a different problem. Feel free not to use smtp-auth,
or require VPN first, or whatever makes you happy.
--
/Jason
Re: preventing authenticated smtp users from triggering PBL
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On 12/17/10 9:57 AM, Ted Mittelstaedt wrote:
> On 12/17/2010 9:23 AM, Aaron Bennett wrote:
>>> -----Original Message----- From: Ted Mittelstaedt
>>> [mailto:tedm@ipinc.net] Sent: Friday, December 17, 2010 12:20 PM
>>> To: users@spamassassin.apache.org Subject: Re: preventing
>>> authenticated smtp users from triggering PBL
>>>
>>> why are you using authenticated SMTP from trusted networks?
>>>
>>> The whole point of auth smtp is to come from UN-trusted networks.
>>>
>>
>>
>> I think you are misunderstanding. I may be on an unstrusted network,
>> but I want to send email through a host on a trusted network. By
>> authenticating, I can. It was the "trusted host" which authenticated
>> me, and thus SA needs to take that I was authenticated by a trusted
>> host into consideration before applying the PBL rule to the address
>> the mail initiated on.
>>
>
> Right, but a spammer can send a message with the same authenticated
> flag set in the mail header through the standard SMTP port because
> they are manufacturing the headers out of thin air.
>
> My experience with SA is that if it sees that flag anywhere in the
> header, it will assume the mail is safe. I have also had the experience
> with earlier versions of SA that they ignore the flag completely but
> that was fixed a while ago.
>
> Ted
I use Mimedefang with some home-brewed patches I've been trying to get David to include for the last 3+ years.
I look for the local port # that the connection comes in on, and pass it in to SpamAssassin as a hint from the command via --cf=... And port 587 forces a different rule than 25 does.
This can't be forged.
-Philip
RE: preventing authenticated smtp users from triggering PBL
Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> My experience with SA is that if it sees that flag anywhere in the
> header, it will assume the mail is safe. I have also had the
> experience
No, Ted. SA wouldn't accept an authenticated mark from outside its
trusted_network.
> with earlier versions of SA that they ignore the flag completely but
> that was fixed a while ago.
Are you speaking of the msa_network setting then?
Giampaolo
> Ted
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 9:23 AM, Aaron Bennett wrote:
>> -----Original Message----- From: Ted Mittelstaedt
>> [mailto:tedm@ipinc.net] Sent: Friday, December 17, 2010 12:20 PM
>> To: users@spamassassin.apache.org Subject: Re: preventing
>> authenticated smtp users from triggering PBL
>>
>> why are you using authenticated SMTP from trusted networks?
>>
>> The whole point of auth smtp is to come from UN-trusted networks.
>>
>
>
> I think you are misunderstanding. I may be on an unstrusted network,
> but I want to send email through a host on a trusted network. By
> authenticating, I can. It was the "trusted host" which authenticated
> me, and thus SA needs to take that I was authenticated by a trusted
> host into consideration before applying the PBL rule to the address
> the mail initiated on.
>
Right, but a spammer can send a message with the same authenticated
flag set in the mail header through the standard SMTP port because
they are manufacturing the headers out of thin air.
My experience with SA is that if it sees that flag anywhere in the
header, it will assume the mail is safe. I have also had the experience
with earlier versions of SA that they ignore the flag completely but
that was fixed a while ago.
Ted
>
>
RE: preventing authenticated smtp users from triggering PBL
Posted by Aaron Bennett <ab...@clarku.edu>.
> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm@ipinc.net]
> Sent: Friday, December 17, 2010 12:20 PM
> To: users@spamassassin.apache.org
> Subject: Re: preventing authenticated smtp users from triggering PBL
>
> why are you using authenticated SMTP from trusted networks?
>
> The whole point of auth smtp is to come from UN-trusted networks.
>
I think you are misunderstanding. I may be on an unstrusted network, but I want to send email through a host on a trusted network. By authenticating, I can. It was the "trusted host" which authenticated me, and thus SA needs to take that I was authenticated by a trusted host into consideration before applying the PBL rule to the address the mail initiated on.
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 8:51 AM, Jason Bertoch wrote:
> On 2010/12/17 11:47 AM, Ted Mittelstaedt wrote:
>> And what prevents a spammer from forging this into a header and
>> bypassing SA? Just askin.
>
> Without checking, I'd guess that matching an authentication header with
> an address in trusted_networks would be sufficient.
why are you using authenticated SMTP from trusted networks?
The whole point of auth smtp is to come from UN-trusted networks.
> If your
> authentication server is relaying for spammers, you've got an entirely
> different problem.
>
No, not really. You as an administrator cannot control what your users
do and if your users save their authenticated SMTP passwords into their
e-mail clients then later allow their machines to be cracked, then the
crackers get the auth password and away they go.
Ted
Re: preventing authenticated smtp users from triggering PBL
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/17 11:47 AM, Ted Mittelstaedt wrote:
> And what prevents a spammer from forging this into a header and
> bypassing SA? Just askin.
Without checking, I'd guess that matching an authentication header with
an address in trusted_networks would be sufficient. If your
authentication server is relaying for spammers, you've got an entirely
different problem.
--
/Jason
Re: preventing authenticated smtp users from triggering PBL
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 12/17/2010 8:41 AM, Jason Bertoch wrote:
> On 2010/12/17 11:28 AM, Aaron Bennett wrote:
>> I've got an issue where users off-campus who are doing authenticated
>> SMTP/TLS from home networks are having their mail hit by the PBL. I
>> have trusted_networks set to include the incoming relay, but still the
>> PBL hits it as follows:
>>
>> Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
>> by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
>> for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
>> Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
>> [98.216.185.77])
>> by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
>> for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
>> From: "USER NAME"<SE...@clarku.edu>
>>
>> Despite that internal_networks and trusted_networks are set to
>> 140.232.0.0/16, the message still triggers the PBL rule. Given that I
>> know that (unless there's a trojaned machine or whatever) I must trust
>> email that comes in over authenticated SMTP/TLS through the 'cmail'
>> host, how can I prevent it from hitting the PBL?
>
> Based on the headers you included, there's nothing indicating the sender
> was authenticated. Are you using the following in postfix?
>
> smtpd_sasl_authenticated_header yes
>
And what prevents a spammer from forging this into a header and
bypassing SA? Just askin.
Ted
Re: preventing authenticated smtp users from triggering PBL
Posted by Jason Bertoch <ja...@i6ix.com>.
On 2010/12/17 11:28 AM, Aaron Bennett wrote:
> I've got an issue where users off-campus who are doing authenticated SMTP/TLS from home networks are having their mail hit by the PBL. I have trusted_networks set to include the incoming relay, but still the PBL hits it as follows:
>
> Received: from cmail.clarku.edu (muse.clarku.edu [140.232.1.151])
> by mothra.clarku.edu (Postfix) with ESMTP id D4FC2684FEA
> for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> Received: from SENDERMACHINE (macaddress.hsd1.ma.comcast.net
> [98.216.185.77])
> by cmail.clarku.edu (Postfix) with ESMTP id 82F21901E48
> for<RE...@clarku.edu>; Tue, 7 Dec 2010 00:11:24 -0500 (EST)
> From: "USER NAME"<SE...@clarku.edu>
>
> Despite that internal_networks and trusted_networks are set to 140.232.0.0/16, the message still triggers the PBL rule. Given that I know that (unless there's a trojaned machine or whatever) I must trust email that comes in over authenticated SMTP/TLS through the 'cmail' host, how can I prevent it from hitting the PBL?
Based on the headers you included, there's nothing indicating the sender
was authenticated. Are you using the following in postfix?
smtpd_sasl_authenticated_header yes
--
/Jason