Thomas Bolioli wrote:
> Dan Horne wrote:
>>> I see a couple of ways that this can be remedied, most of
>>> which is acceptable. a) Whitelist all of the users (or the
>>> entire domain) for every domain on the system [obviously bad
>>> since it allows spammers to spoof from headers with impunity
>>> even with SPF setup]. b) set up second machine to be a second
>>> MTA and have users send email from machine 2 which then
>>> relays to machine 1 [waste of a machine and energy to run
>>> that machine]. or c) there is some configuration I am
>>> missing. Does anyone know what I can do to fix this?
>>>
>>>
>>
>> Set up SMTP AUTH and require your users to log in to send email. If I
>> understand correctly Spamassassin automatically trusts mails sent via
>> SMTP AUTH.
>>
> Thanks for the response. SMTP auth is set up so there must be something
> I need to do to tell SA that it was auth'd.
> Any ideas?
For sendmail and client IP's that include a "(may be forged)", there is a patch
that will be included with the next release.
You can see what is going on by testing one message, with `spamassassin -x -D -t
< sample.eml`, look for the "Relays" lines, something like this one:
[824] dbg: metadata: X-Spam-Relays-Trusted: [ ip=2.5.1.1 rdns=mail.l.com helo=
by=ca.org ident= [EMAIL PROTECTED] intl=1 id=J9POUJ-0001MC-JY auth= ]
If the "auth=" is empty, as above, then the authentification was not recognized.
In this case look at the messages' corresponding Relay header, which in my
example was something like:
Received: from M (dsl-1-1-7-1.prod.com [189.149.70.163] (may be forged))
(authenticated bits=0)
by mail.l.com (8.13.8/8.13.8) with ESMTP id kB3G26P6019032
for <[EMAIL PROTECTED]>; Sun, 3 Dec 2006 10:02:16 -0600 (CST)
--
René Berber
