> If I set up the SPF TXT record for certain customer domains on our
> DNS Server. Legit messages should be comming only from our
> Mailservers IP.
Right, that's what you specified when you created an SPF record. Many
seem not to quite to grasp this, but all SPF does is set an acceptable
use policy for a domain registered to you. You decide whether you can
spend the time to come up with a policy that covers all the mail
bases--just as you'd have to come up with a robust AUP for an ISP or
corporation. If you can't come up with a policy, even given SPF's
flexibility, you shouldn't publish one. Once you come up with policy
and make it available to the public Internet, any server a using
publicly accessible records for your domain must take consistent steps
to comply with it. This includes your own servers, unless they point
to an internal DNS that doesn't reflect the public records.
> Now one of our customers send a legit message trough our mailserver.
Your use of "legit" is confusing. Rephrased, an SPF TXT record _is_ a
legitimate use policy. For the purposes of an SPF check, there is no
greater arbiter of legitimacy than that record.
> Wouldn't this create a wrong result for SPFFAIL?
There are no "wrong" results with SPF (provided the SPF parser is
written correctly). If you're saying that you set up an SPF record
that will cause a fail for an IP or PTR that isn't listed explicitly
in the record, and you send mail from such an IP, then a fail isn't
wrong! Either the policy is wrong outright, or you haven't created a
setup in which you can use non-SPF tokens (such as SMTP AUTH) to
counteract the weight you're assigning to SPF FAIL.
> Do I have to whitelist all local users in order to avoid false
> positives.
Well, what's a local user? If a local user is an AUTHed user, then use
WHITELIST AUTH; if a local user comes from a known IP range, then you
can whitelist that IP if you think that's safe, or add that IP range
to the SPF record (which will allow for sensitivity to other tests). I
don't think "local user" is really such a helpful term, since it could
cover just MAIL FROM: @example.com (as Declude uses in
short-circuiting some tests), or something more "true."
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
