Re: [Declude.JunkMail] Declude and SPF

[Matt]

Markus, I wouldn't say "only" in the case of SPFFAIL as there are other situations that might warrant different use.  I believe that you are dead on as far as SPFPASS goes though. One thing of note is why I choose not to implement SPF at this time.  Because I don't have control over how my customers use their E-mail, i.e. what server they send it through, and because many don't send it through mine, including everyone who's ISP has blocked port 25 outbound, the only type of record that I could use that would be of any value to others would be "?all", meaning that E-mail from my domains can come from anywhere (and it most certainly can of course). Some might say that knowing "+a and +mx" are useful, however if you don't apply negative weights for passing these, as you shouldn't, then there is hardly any value to adding those records if you are going to have a "?all".  If I was however to restrict the record to "-all", figuring that 99% of my clients send from the optimal A or MX IP, I would then be opening up my other customers to the will of any administrator in choosing how they handle a SPFFAIL result.  It has been suggested around here by at least two people that this should constitute a Hold.  So for now, without SPF configured, I'm not subjecting my clients to the whim of other administrators, especially when many of them are blocked on port 25 and unknowingly use mail forms that use their own E-mail address as the sender. Matt Markus Gufler wrote: 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. -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================