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'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

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

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.

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.