Quoting Markus Gaugusch <markus@gaugusch.at>:

I would suggest to use SPF (http://spf.pobox.com). This way you can restrict the IP's that are allowed to send mails that end with your domain.

Unfortunately, SPF breaks forwarding. For instance, if I host my web site at a hosting provider and have the e-mails sent to it forwarded to my cable modem account, SPF will block them. There is no way around this without the hosting provider changing their e-mail setup. I previously announced my mail server with SPF until my customers started complaining that they couldn't send mail to such people. As an ISP, there was nothing I could do about it, short of removing the SPF entries from my DNS. SPF is not a viable solution.

On Wednesday 21 July 2004 20:54, Dirk Schreiner wrote:

SPF causes tons of trouble and no real benefit.

SPF works for me and for about 20.000 registered domains that publish SPF records at the moment (http://spf.pobox.com/adoption.html). Yes, checking SPF records on inbound e-mail breaks forwarding, but there are ways around this. Remailing instead of forwarding is one of them. If your hosting provider doesn't support this, go to one that does or exclude their mailservers from SPF checks. There is a whole lot of difference between publishing a SPF record and checking for SPF on inbound mail. Publishing a SPF record doesn't necessarily break things. You should either have all your domain users use your servers for outbound mail (SASL can be used for that) or be lenient in the fallback (publish ?all or ~all as last parameter). Regards, Arjen

On Wednesday 21 July 2004 21:44, suse@rio.vg wrote:

I set up my servers to publish SPF, but not check it for incoming mail. My customers attempted to e-mail people who used domain hosting sites that did not specifically modify their software for SPF. My customer's e-mail did not reach their recipients.

Then the recipients obviously use an ISP that does check SPF records *and* they use forwarding. In that case they have a problem with their ISP. You could have prevented their problems by publishing ?all in your SPF records and the e-mail should get through, even when they use forwarding. As an example, AOL and Amazon for instance do this, precisely to prevent the problems you're picturing.

The whole problem is that the breakage is not at the publishing domain nor the recipient, but at the middle man.

No, it is the ISP of the recipient in combination with the forwarding of e-mail. If the ISP decides to check for SPF records but the customer wants to forward e-mail from their vanity domain to this ISP there is a problem. The ISP should allow their customers to switch off the SPF checking for them or the recipient should ask their hosting providers to switch from forwarding to remailing.

The "ways around" all involve convincing the middle man to change their software.

Not at all. You can decide to end your SPF record with ?all and there will be no such problem, since the SPF neutral will allow the e-mail through.

As the originating ISP of the e-mail, there is nothing I can do.

See above. Publish ?all and you'll be fine. Domains checking SPF properly will pick up that the e-mail came from a legitimate client and people using forwarding will still be able to recieve their mail. Regards, Arjen

On Wednesday 21 July 2004 12:40 pm, suse@rio.vg wrote:

Basically, SPF is just a "feel good" lark.  In order to prevent it from breaking current e-mail, you have to break SPF.  Then the SPF people say "Wowie!  Look at all the people using SPF!" except that the biggest and probably most of the others use the "all" tag that says "everyone is considered trusted!"  What's the point in publishing SPF if you publish that the entire internet is considered trusted for your domain?

So the emperor has no clothes, is what you are basically saying? ;-) -- _____________________________________ John Andersen

Quoting Arjen de Korte <suse+security@de-korte.org>:

In a few years time, the '?all' will become obsolete and '-all' will be all that you want at the end of your SPF record. Or risk that people will forge mail from your domain.

[...]

Publishing '?all' at the end of your SPF record doesn't break it. If you designate legitimate senders, they will pass however.

[...]

I suggest you first read up on SPF before you're making a fool of yourself more than you already did. Only when receiving a SPF 'pass', e-mail is considered legitimate, SPF 'softfail' and 'neutral' will still be accepted, but is not considered to be legitimate. Only in case of SPF 'fail' a message should be bounced.

[...]

SPF 'neutral' is NOT considered trusted. And by the time that most hosting providers will have switched to remailing instead of forwarding (I know, this will take time) 'neutral' and 'softfail' will be almost equivalent to 'fail' for Bayesian filters, as spammers and virusses will only be able to get through by using domains which default to 'neutral' or 'softfail'.

...

Oh, and I'm not "picturing" it. It actually happened to me. I was a big proponent of the idea of SPF until my customers started complaining.

You must have published a '-all' at the end of your SPF record and failed to oversee the consequenses of doing this.

You seem to be on some sort of holy crusade in regards to SPF. I'm not. Personally, I'm in favor of just about anything that will reduce spam without angering my customers. There are far too many people on these holy crusades. Other people talk about the purity of SMTP and not mixing up layers. Personally, I don't care. I just want it to work. I didn't have "?all" in my SPF records because http://spf.pobox.com mentioned NOTHING about that being away to avoid problems with forwarding. Maybe somewhere in the mailing list, but not in the main docs and not in the FAQ. You may have time to go crawling through mailing lists for your pet crusade, but I don't. You mention "softfail", "neutral", and "passed", but they're all the same. In each case, the mail is delivered. Setting "?all" means that anyone can spoof my domain and it will be delivered. What's the difference between that and what we have now? Since the large providers use "?all", SPF is at best a placebo, at worst it breaks legitimate messages. The docs say, "Do the above lines describe all the hosts that send mail from your domain? Then use '-all'". All the mail for my domain comes out of a single network that was specified. I guess you consider someone a fool if they follow the documentation without reading three thousand e-mails off the mailing list. When I heard about SPF, it sounded like a good idea, so I decided to post my mail network as the only trusted network for my domain, figuring that it couldn't cause any harm and might help some other people out. I decided that later, after SPF had matured, that I would look into using it to block e-mail on our own servers. Unfortunately, the first step didn't work out. I'm just a sysadmin. I don't have a cause. I just want things to work. I would love SPF to work. But I don't have time to spend weeks on your pet crusade. I don't understand why SPF blockers don't simply check ALL of the received headers and "pass" if the proper mail server is anywhere in the chain. It's a simple and obvious fix for the problem of forwarding without forcing anyone to change their mail servers...

suse@rio.vg writes:

I don't understand why SPF blockers don't simply check ALL of the received headers and "pass" if the proper mail server is anywhere in the chain. It's a simple and obvious fix for the problem of forwarding without forcing anyone to change their mail servers...

"For every complex problem there is an answer that is clear, simple, and wrong." -- H. L. Mencken 1) You don't have the Received: headers until the SMTP handshake is completed and the data is transferred. At that point in the protocol, there is no way to reject the mail; the receiving MTA has taken responsibility for it. 2) Any Received: header other than the first (i.e. the last one generated) could be forged. You need to walk back through the headers and identify, at each step, whether you trust the "received by" host to correctly identify the "sent from" host. This is a nontrivial task. -- Alan Hadsell If brute force doesn't work, you aren't using enough.

On Thursday 22 July 2004 18:01, suse@rio.vg wrote:

Quoting Alan Hadsell <ahadsell@MtDiablo.com>:

...

suse@rio.vg writes:

And for every complex problem there are a dozen solutions that create more problems than they solve.

1) Why is it necessary to block before data is received? SpamAssassin and DSPAM don't. In fact, I much prefer systems that do not block at the SMTP. If I receive the e-mail and mark it as spam, it can be checked later. If it's blocked at the SMTP, there is no recourse.

2) I could also create subdomains on the fly, generate SPF entries, and spam past SPF to my heart's content. Until SMTP is completely replaced, there are always ways around things. The Spammers are clever.

I agree with you about SPF's problems, but I don't think spammers can make subdomains on the fly for my domain. This is not how DNS works. Only I can do that, if I have access to my own DNS zone.

Currently, SPF creates a blockage that is exceedingly difficult to remove. Trying to convince a hosting site to change it's e-mail system isn't trivial. People get REALLY upset when their e-mail doesn't work, so companies are very wary of making any changes that could potentially cause problems.

Again, I do agree with you for the most part, but this expectation of email that "always works" is SO 3 years ago. Nowadays, people are just lucky to notice they have a few non-spam messages buried with the rest, just one second before pressing the <<delete>> key. Spammmers, spamassassin, viruskillers and (network- or otherwise)blacklists have taken care of that.

I've noticed a correlation between proponents of SPF and people that never have to actually deal with customers. If I ran some internal corporate network, SPF would look an awful lot better. When you have a captive audience, it's much easier to deal with complaints.

Sure, but still. I've dealt with numerous issues, from easynet blacklisting "yeah, because your mailserver IP is in a dialup pool" to mailservers that stubbornly reject mail from an IP that has no valid reverse PTR record. And you try to convince your big colo hosting company to set those PTR records straight. I've been there, and that wasn't one of the the lesser hosting companies either... way too often, this shit is just beyond your control. Maarten -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER

On Thursday 22 July 2004 21:28, Dirk Schreiner wrote:

Hi,

maarten van den Berg schrieb:

...

I agree with you about SPF's problems, but I don't think spammers can make subdomains on the fly for my domain. This is not how DNS works. Only I can do that, if I have access to my own DNS zone.

read ;-)))

Thanks, real interesting read ! I already knew of cache poisoning, but I somewhat underestimated its chances of success I guess. Not that I am vulnerable, according to that test, but it is always good to be informed.

http://www.securityfocus.com/guest/17905 http://ketil.froyn.name/poison.html http://cr.yp.to/djbdns/bugtraq/19991114052453-12962-qmail@cr-yp-to

Dirk

<snip huge sig> Maarten -- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER

Hi, Markus Gaugusch schrieb:

On Jul 21, Dirk Schreiner <dirk.schreiner@tria.de> 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

On Jul 21, Dirk Schreiner <dirk.schreiner@tria.de> wrote:

Markus Gaugusch schrieb:

...

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. incorrect (old-style)? Could you please post the RFC with the "new-style".

SPF suggests remailing instead of forwarding. I'm pretty sure that this does not bother any RFC. The old method may not be incorrect, but it is just incompatible with SPF. Sorry for the wrong wording. Your suggestion with signatures are also nice, but I think that 1 million administrators are easier to convince to perform infrastructure upgrades, than billions of (mostly stupid) users. I don't think that SPF is so bad, and I haven't heard of any other problems than forwarding. Digital signatures, though, are something that probably not even everyone on suse-security has tried. And I don't want to see the next MS Outlook version with integrated signatures that will break like everything else they make. Infrastructure security should be done by administrators, not by end users. Although there are still too many stupid admins out there :( And yes, I know, that the forwarding problem doesn't hit me, but the innocent receiver who forwards mail from my account to his SPF-protected domain via a non-SPF aware host in the middle. But if that case happens, I could either send mails to him directly, or try to convince the "middle" host owner to do something against the sky-raising amounts of spam and do remailing instead of forwarding.

Dirk Going sleeping.

BTW: if anybody is not amused about that long signature. I cannot go around this because company GW is doing that. And using my host`s SMTP-Server is not possible due to people checking Reverse-Lookup and doing SPF. :-/

You could at least use sigdashes ("-- ", the trailing blank is important!) to make users of good mail clients not-so-annoyed :) Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \

Please, unsubscribe me. Thanks.

Your ignorance of email headers that contain all information you need to unsubscribe is regrettable. This way you bother several thousand subscribers. You are unsubscribed. Roman.

Quoting myself:

[...]

Oops! This was meant to be sent as a reply to a different message on a different mailing list. I probably should not use two mail clients at the same time. :-) Sorry folks! -- Mit freundlichen Grüßen / Yours sincerely Dipl. Inform. Ralph Seichter HORUS-IT Ahornweg 10 D-57635 Oberirsen Tel +49 2686 987880 Fax +49 2686 987889 http://horus-it.de/