>> John, not wanting to confuse his customers by sending the information via his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ server. <<
That would not be wise. Instead, he'll use SMTP AUTH on port 587 to send his mail using the @QRS.com address via the QRS.com mail server. Declude WHITELIST AUTH takes priority over SPF and Imail 8.2x is capable of answering on more than one port (e.g., 587). I've been an early adopter of SPF, running it for quick a long time and don't have any problem with my own customers "failing" SPF. SPFPASS has to be used with care, I agree. If spammers use SPFPASS then their SPF record makes it easy for us to block all their "permitted" IP addresses, since they are "committing" themselves to those. I think it's a good idea to first check the IP blacklists and NOT give credit for SPFPASS unless the IP blacklists come back clean. In essence, you are giving SPFPASS credit only to counteract some other tests (such as content and header checking). (One could even go a step further and check multiple trusted blacklist sources - if an IP is listed in several, the SPFPASS could be used to ADD weight - but that's just a theory.) Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tyran Ormond Sent: Thursday, September 08, 2005 09:59 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] SPFPass - good or bad? On 09:01 AM 9/8/2005 -0400, it would appear that Darin Cox wrote: >Be careful of using spfpass. Spammers can use SPF, too! > >We do not give any credit for passing SPF, only a penalty for failing.... >which too many email admins set up but allow their networks to send >email from machines not listed in their SPF record :(. > >Darin. Personally, I find SPF to be worthless in all cases. To begin with, the only SPAM it could halt (in a perfect setup) is SPAM sent through unauthorized servers. As already noted, SPAM can be sent legitimately from a server using SPF. Also, current "best" practices break SPF. The current wisdom is to block outgoing port 25 and force the clients to only send mail through the local mail server. That sounds good on the surface but such a practice and SPF cannot live together. Example: Employer QRS.com has a beautiful SPF record, clean SPAM record and encourages their employees to telecommute. John, a QRS.com employee, is working from home today and needs to send some updated information to one of QRS.com's customer. John's ISP (ISPXYZ) blocks outbound 25 and forces its clients to send all email through the ISPXYZ mail server. John, not wanting to confuse his customers by sending the information via his ISPXYZ account, uses SMTP Auth and sends his email using his @QRS.com address via the IXPXYZ server. That message, which is completely legitimate AND which follows all current best practices, will fail any SPF test. True, John could request that ISPXYZ be added to the QRS.com SPF record but do you really want to keep track of every mail server that your employees may have legitimate cause to use in sending mail from your domain? I know I don't and we have only a small number of employees and would only have to deal with this while employees are out of town attending conferences or training. The only way SPF could be used reliably is if A) port 25 were thrown wide open again and B) mail servers were reconfigured to ONLY send mail for their own domain. Then in the above scenario, John sends his QRS.com mail from home via the QRS.com mail server and both QRS.com's and ISPXYZ's mail servers would refuse to send mail for any domain but their own. Then all QRS.com's mail would pass SPF and all the mail that ISPXYZ's server sends would also pass SPF. Tyran Ormond Programmer/LAN Administrator Central Valley Water Reclamation Facility [EMAIL PROTECTED] --- 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. --- 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.
