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
