> No, it's not completely useless. Even if you can't query > _your own_ SPF record unless it's set to accept wildcard > sending IPs--and you can't use WHITELIST AUTH for those > IPs--you can still publish an internal DNS zone for your > domain that doesn't contain an SPF record, while publishing > a more restrictive policy in your public DNS record.
Ok. Interesting to know. Why I can't see anything about this on the SPF homepage or anywhere else? In my opinion this are very important informations for anyone who want's to set up SPF-Checks and SPF-Records. So: Use SPFFAIL only with Imail v8+ and enabled SMTP-AUTH whitelisting or with whitelisting of internal IP's from whitch your users/customers connect from. or set up private SPF-Records visible only for your own MTA. In additon: Don't use SPFPASS because - as usual - Spammers are much faster then most Mail-Admins. Correct? > In order to deploy SPF, you definitely need to have a > consistent idea of which sessions deserve elevated > privileges in theory--and which of those sessions you can > detect in practice. And so anyone should make his own understanding without a discussion on this list? Maybe great part of all who are running SPF tests doesn't know about this special "issues". Keep in mind that the defensive effect of SPF-Records can only be as good as the reliability of SPFFAIL on remote MTA's side. Or in other words: My SPF-Records are pretty useless if other Admins score SPFFAIL very low because they can see too much wrong results for this test. Markus --- [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.
