Hello Andy Andy Smith wrote: > On Wed, Jan 28, 2004 at 11:40:53PM +0100, Fabian Wenk wrote: > > They will do, as they make enough money from one run of sending out > > spam. > It would still be incomparably better to how it is now, where DNSBLs > must list IP addresses because all domain names are forged. There > are a lot more IP addresses than domain names.
For spam filtering first I did use only DNSBLs, but a it was to troublesome I set up SpamAssassin where the DNSBLs make only a part of the whole spam dedection process, also the content anaylsis and the check with Systems like DCC, Pyzor und Razor help to discover the spam, and it works pretty good. Usually I have around 1 false negativ per week, and I didn't have a false positiv in months. I get around 20 to 40 spam emails every day. > You really cannot blame SPF for the failings of other processes. As I do not blame SPF for this, but SPF was brought up in the discussion about spam. > I say the point of SPF is only to authenticate a sender, nothing > more. Once we are able to say with some degree of certainty that a > mail that came from [EMAIL PROTECTED] really did come from the people > in charge of example.com, then pressure can be exerted on every This is sure a good point. > service provider for example.com. Right now, this can't be done > easily, it requires masses of research. SPF will make life so much > better for anti-spammers that I am willing to cheerlead for it like > this to all those who think "this won;'t fix spam => it is > pointless". As I said above, this thread brought up SPF because the discussion was about spam. To be sure if the email you receive is really from the person you think there are also some other tools available like PGP which can also keep your emails private if needed/wanted. I know, it is not very easy to use for the users, even I don't have it. > In reality it would only need a couple of the large email service > providers to use it before spammers are economically affected. If > the likes of AOL, MSN, Yahoo!, Outblaze, and a few large broadband ISPs > would start to use it then it doesn't matter what all the rest of > the companies in the world combined use, this is enough to force > spammers to change. But if they are using SPF only eMails from domains which have SPF conform DNS entry will be able so send emails to them, right? .oO(I really should once read all about SPF, but it always comes up in discussion about spam, and there it won't help respectively is not the right solution for it) > I have heard rumours that most of the companies I have named above > are working on their own SPF-like scheme which will not be open like > SPF, will not take much input from the internet community at large, > and on the whole will probably not be as nice for others to conform > with as SPF is. You will conform with it anyway because you cannot > say to your customers, "sorry, we aren't able to send your email to > AOL anymore". So in the near future I see it either that the > Internet community embraces an open standard or else it has a closed > standard forced on it by the AOL/MSN/Yahoo!s of this world. Sure this is a bad thing, but it also shows that a solution on top of the existing SMTP won't really work. Maybe some totaly different better designed way of sending emails would be needed. It is a problem to switch a such widely used system to change with a new extension, but also changing to a absolutly new system would be difficult. There is also TMDA (http://tmda.sourceforge.net/), which checks a whitlist, an if the sender of the email is not on it, it will send back an email which needs to be confirmed, which usually only happens if a real user gets it. Probably there are also some other solutions around with different approaches to solve similar problems with email and/or spam. Something which belongs not to this tread I'll answer it in the other thread about the umlaut domains. Today we where playing around a little bit with it and it shows that this also will get some trouble, and not everybody would be able to use the new domain names. > > Not the trojan is sending out spam, it is only working as a mail relay > > for the spammer to send out his spam. It will send out the spam with the > > domain the spammer acquired and set up for sending out spam. > > In a world where something like SPF is widespread, there will be so > much more that recipients can do about cases like this. For a start > the recipient can send email that comes from domains with 0/0 in > their SPF, or with no SPF, through much harsher content filters. So, I think I should really read the SPF documentation. ;) I was thinking, that if you are using SPF for receiving mail all the domains which wanted to send you email needs to set up there dns zones right. Else if you can choose on a per domain basis if you want to check for SPF or not the administrativ work will be a lot. > Also once there are "domain trust" databases available, email from > domains with no established history can also be treated as > suspicious. Is this also a part of SPF? > Those are just a couple of the most obvious approaches that come > to mind. As I said, SPF is meant to work with other antispam > technqieues, not as a silver bullet by itself. Sorry if I got you on the wrong feet, but as I said above, when SPF came to my attention it was always with the intention to solve the spam problem, and for this it is not the right solution, as you also said. And I'm even not sure, if it is the right solution to solve the authenticity problem with email in general. There is an other thing coming to my mind. What does a large web and mail hosting company do? Probably they will maintain one mail server for all there customers which they can use to relay outgoing emails. So who keeps there customers from fakeing sender domain of other customers of this hosting company? > > I guess it needs to be used by all domains from which you would like to > > receive email? > There is no reason why you would stop accepting email from domains > that do not have SPF records. What you did about them would be a But then it probably would be needed to be configured on a per domain basis? > policy decision for you, just like many people take policy decisions > on mail from IPs that have broken reverse DNS, or that give a > wrong/invalid host in their HELO. It is just one more metric that > we can use to decide how to handle mail, but it is an immensely > useful one. Sure there are also this metric to put in the email receiving process. I currently use only the check if the sender domain does resolve as it was the default with my sendmail setup when it was out of the box. The other checks I don't use, as to many of the people I kown to relay there emails out directly from there Linux/*BSD box which has a dynamic IP address with a reverse DNS which doesen't match the host name. > What I'm saying is, these are real problems with SPF that will cause > problems for the business models of many people who would like to > use it, as opposed to the things you are saying which to me are just > complaints about how "SPF won't kill spam so SPF is pointless". I say that it is pointless in the approach to kill spam, for the authenticity of email it could be a solution, but I didn't yet check out what other solutions are around to solve this problem. > But all of this is answered by the various documents on that site, > and if not then the SPF mailing list would be better. I will look into this once in the future, but not right now, as email for me (and some friends and family which are using my mail server) is currently working just fine. > However, I don't think you will be convinced, so I'll leave it > there. You do just fine and made me think more about the email authenticity problem. So to me this picture http://www.westorange.k12.nj.us/Roosevelt/images/don't%20ever%20give%20up.jpg comes up to my mind, as I have seen it hanging in office more the once. bye Fabian ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
