Dan,

Our little 2 cents. We handle mail for about 4,000 domains, which means all of them are using our SMTP servers. If they wish to send email they must use our SMTP servers as their "outgoing SMTP server" in their email client configuration. Thus our SPF records are very simple, since all mail from those domains will always originate from the IPs of our SMTP servers. We do not have to worry about the user's IPs since they will not and must not send email any other way that is not going thru our SMTP server.

We then have the separate issue of configuring the SMTP server so that only those clients are able to relay thru it, but that is a different subject that should not be related to SPF.

Roberto F.
LogSat Software

Roberto,

I agree but that brings me back to the discussion we had earlier about authentication on the SMTP server.  Getting our remote users to change their SMTP server will be a pain but that is expected and accepted but we have little, if any contact with many or the users outside the US (their parent offices can communicate with them) and we still have the issue that most have DHCP IP's.  So .... I am still trying to figure out an authentication method ... like somehow using our pop servers userlist ... Good topic for a later discussion.

Regards,

Dan S.

Roberto's Idea works. I've been migrating to that solution for a little while now.

I just use smtp authentication and setup a pc for email relaying. It has some smarts to know to relay the message out or send it to our mail servers. Customers have actually reacted well to this because they don't have to worry about using a blacklisted dynamic internet ip. So most customers have welcomed this. As an incentive to relay mail through I added an anti-virus layer so that all outgoing mail is scanned as well.

Kevin

The only problem I have is that SMTP Auth is not available on my existing relay server.  And the vender has no plans to support it but I am trying to work a diff solution.

Dan

Fire me an email dan, we should be able to work something out, I have a few ideas.

I agree that ideally everyone would instantly run SPF, but let's take it realistically, one domain at a time.  The best thing we can do as ISP's is continue to educate, participate and promote SPF.  As adoption of SPF increases, so will the benefits for all using.  Even if only one more domain each week is using SPF, we're all better off because of it.

The ?all Neutral default is designed for domains that are in the process of getting IP's and Hosts registered.  Use the log files and log file reporting to identify and add legitimate  IP's Hosts for those domains in the registration process.  I'm updating my SF2DB.exe program to capture SPF results and already gives me a report on sender host names and IP's for a given client domain.  If  you need better parsing of log files to a database let me know.

Keep pushing your clients via newsletter, etc and of course any time they complain about NDR's and other emails with fraudulent headers, remind them that there is a solution now.

Matt,

I hate "Beating a dead horse" here but there are real situations that make any solution except some sort of authentication very problematic in our ISP situation.  And bare in mind that this is not stopping me from using and fully supporting SPF.  I am a very big supporter of it.

Here is one simple example:  We have a service called iPass that many of our users use.  Simply, what it is, is a dialer that the customer installs on his laptop.  Then when the customer goes to Tokyo, the dialer finds a local, iPass partnered ISP.  The ISP in Tokyo queries OUR RADIUS server to authenticate the user exactly like he was dialing into our pool with the exception that we do not (can not) hand off an IP ... the local ISP does.   We have no way of ever knowing what that IP is going to be in advance and in fact, have no way of knowing what it is even once the user is authenticated.  Therefore, if the user opens up his Outlook and tries to mail to a service that supports SPF, it gels blocked by that service because our SPF record can't possibly have the correct IP's in it.  The workaround is that they use our webmail but then all the normal addresses and contacts the customer has in Outlook are not available and he still needs to download his mail after reviewing it in webmail.

This is only one example.  We also have customers whose employees live all over the world and the same situation applies.  For those domains, we still have not put SPF records in because we do not have any work around.  So ... no log parsing in the world will help in these cases since the IP'a are a moving target.

Bottom line, I still feel that SPF is a real good trek in the correct direction but there are issues that nee to be addresses and I don't have the answers yet.

Regards,

Dan S.

Outlook does not relay mail, of course, so they have to be sending through somebody's server, yours preferably.  If the ISP and theirfore the SMTP server that each user uses changes everyday, or at a frequency that you feel would not be worth registering then that domain would not be suitable to use SPF unless you use a central SMTP outgoing server at your facility. Based on your posts then you should have all your users setup Outlook to SMTP via non standard port, that is not ever blocked by the dial up folks, via your servers.  That way you don't need to worry so much about authenticating the roming Outlook clients.

Matt,

Sounds good in theory but we have thousands of  "roaming" users.  We rarely, if ever have any real contact with them and most would not know how to change their outbound port settings,  It would be a tech support nighmare.  And,  NOT having SPF in not going to be an option if I head the handwriting on the walls correctly.  Not haveing an spf recors will be enough to cause blocked messages.

I am not asking for answers ... I just hope that other dns based security will be adopted as alternats to simple SPF  Or, ... hmmm ...not sure I have an "or"!

Dan S.