Hi, Markus Gaugusch schrieb:
On Jul 21, Dirk Schreiner
wrote: Full ack ;-)
SPF causes tons of trouble and no real benefit.
I've been using it for more than a month now and i haven't had a single problem. It may be a problem for larger setups with users that are
Oh, not those using SPF get the problem. They just loose customers, not being able to contact them ;-))
distributed through the net. But most private domain owners and smaller companies should be just fine with it.
Oh yes, just paying some more money, they are fine. :.-(( Just ask the customers of t-online. And this is why _big_ providers like AOL support SPF. Less traffic, and more money from the User.
Yes, it breaks forwarding. But facing the amount of spam, the number of mails that bounce because of incorrect (old-style) forwarding should be neglegible.
If anyone here finds a better solution, without breaking anything in the existing system - you are welcome to tell us. I think that SPF is the best we can get without breaking too much of existing SMTP.
SPF goes a logical way - the domain owner does not only tell which machines receive his mail (MX), but also which machines are allowed to send mails with his domain.
Hey, if this is logical, then we should go one layer down, and verify the IP-Address using the Mac-Address saved in the DNS-System. (Oh, could cause Problems with ATM, SCNR) Or we should force any person, sending a Postcard, to use the registerd postbox. (Maybe this fights paper spam ;-)) Traveling persons are forced to fax home, where the fax is printed onto the postcard and then thrown into the registered postbox. (Have fun at your next vacation.) As you are writing, SPF _is_ breaking existing SMTP. (IMHO in many way`s, not only if one is forwarding.) SMTP is a routing protocol, and as any routing Protocol it has to use a routing table to find the target. The routing tables are saved in DNS as this was the easiest way to do this. But as you can use NAT for IP there are similar ways to do so with SMTP, and as you can use asymetric routing with IP, you can do so with SMTP. SMTP (as the name says) is the transport layer for Mail communication, and as UDP in the OSI-Layer 4, it is just DATAGRAM based and _not_ reliable! (Hey, we should use SNMP to make UDP reliable. SCNR) So, if anyone wants to verify if the _person_ is allowed sending the mail, the check has to be done at higher Level. It can easily be done by using Key Servers (Announced by the DNS _key.domain.com) and signing the Mail-Header, that is seen by the user. So neither POP, IMAP, EXCHANGE, nor SMTP are broken. Check is done by Client, or Company Gateway. Signing is done by client or Company Gateway. This is easy, reliable, but maybe patented. I don`t know. Dirk
Markus
TRIA IT-consulting GmbH Joseph-Wild-Stra?e 20 81829 Munchen Germany Tel: +49 (89) 92907-0 Fax: +49 (89) 92907-100 http://www.tria.de -------------------------------------------------------- working hard | for your success -------------------------------------------------------- Registergericht Munchen HRB 113466 USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600 Geschaftsfuhrer: Hubertus Wagenhauser -------------------------------------------------------- Nachricht von: dirk.schreiner@tria.de Nachricht an: suse-security@suse.com # Dateianhange: 0 Die Mitteilung dieser E-Mail ist vertraulich und nur fur den oben genannten Empfanger bestimmt. Wenn Sie nicht der vorgesehene Empfanger dieser E-Mail oder mit der Aushandigung an ihn betraut sind, weisen wir darauf hin, da? jede Form der Kenntnisnahme, Veroffentlichung, Vervielfaltigung sowie Weitergabe des Inhalts untersagt ist. Wir bitten Sie uns in diesem Fall umgehend zu unterrichten. Vielen Dank The information contained in this E-Mail is privileged and confidental intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient or competent to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this E-Mail is strictly prohibited. If you have received this E-Mail in error, please notify us immediately. Thank you