Hello Daniel
Daniel Lorch wrote:
An other problem will arise if ISPs force there customers to use there own SMTP relay server because they are blocking outbound traffic to tcp/25. So this customers can not use the SMTP relay server of there domain hosting provider with SMTP Auth (and hopefully TLS) on tcp/25.
Valid point. One of the ideas we came up with was to provide customers with a mail address they could send a mail to. A script would then parse the headers and add the server(s) found to the SPF record. Only caveat: some ISPs use more than one IP address for outbound mail so you can never be sure you got all servers in your list.
Ok, this is one thing, an other thing is this:
If the owner of the domain swinog.ch (only as example) is hosting web and mail on your site, but has an ADSL connection with one of the bigger ADSL/Dialup ISP in Switzerland and is using his mail server for relaying outbound mails. This customer now use your special email address with the script to add his ADSL ISP's mail server to his domain's SPF reccords. Now every user from this "big" ISP kann send mails trough the ISP's mail server with the sender address of @swinog.ch and it is coming from the mail server which is registred in SPF for swinog.ch.
That's why you all need to adopt SPF. There is a "include" directive in SPF which would allow us to include, say bluewin's or tiscali's outbound mailservers, _given that they provide these records_.
Why do they need the SPF records, if you want to add it for your domain which you are sending trough there servers?
> http://spf.pobox.com/mechanisms.html#include
Ok, I see, it would only simplify the maintenance of SPF records for other mail servers, when you can use other domain's SPF entries.
Consider it a stub record - as much as SA 3.0's implementation of SPF is .. well .. not yet perfect :) The wider SPF has been adopted, the more sense it will make to support it. Or do you know of any other technology which would allow you to do what SPF does?
No I don't, but SPF will also not work. There are to many drawbacks because of how the sending/receiving of emails works today in the internet.
Let's turn the SPF thing the other way around to the hosting provider like you are doing.
I guess you have only one (or maybe 2 or 3) mail server which your customers can use to relay mails trough SMTP Auth. Now you have in every domain you are hosting set up the SPF entry for the IP of your mailserver. How do you proctect customer A to use customer B's domain for sending emails?
Use your imagination - tell customers they can protect their domains from abuse when they enable SPF. That's another selling point!
Are you still sure, that SPF will protect the customers domain from being abused as sender address?
bye Fabian _______________________________________________ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
