On Thu, 2006-12-14 at 19:39 +0100, Frank Ellermann wrote: > Steve Atkins wrote: > > > Were you around for the fiasco that was SPF? > > SPF FAIL works as designed, stopping forgeries of Return-Paths, thanks > for asking. Spammers understand how SPF works, now it is merely a > self-fulfilling prophecy.
SPF attempts to authorize SMTP clients for where the Return-Path is acceptable. "Working as planned" means messages sent to recipients forwarding their mail will lose messages when sender's SPF records are handled in a "strict" fashion. In the cases where SPF does not break forwarding, it also does not prevent the spoofing of the Return-Path. This problem may explain Bell Canada's "+all". Providing a means to associate DKIM signing-domains with that of the Return-Path could be done within one small DNS transaction that would not break when the message is forwarded, even when handled in a strict fashion. > > our operational experience of throwing away perfectly good > > mail, simply because it wasn't transmitted in a way that > > followed the dogma of the message signers came from. > > As soon as somebody throws mail away for whatever reason they > should be ready for some years in jail, unless it's their own > mail of course. SPF policies SHOULD be checked at the border > MTA during the SMTP session, and at that point in time the > only realistic behaviour of a server is to reject FAIL. Not > accept and throw away, that's madness, nobody would do this. When the forwarded message is refused due to SPF, this message MUST be bounced. Provider could protect themselves by: 1) Not publishing or inspecting SPF records. This works once there is something better. 2) Publishing SPF records with neutral or positive defaults. But then why bother? 3) Modify Return-Paths on all messages. The next problem of modifying Return-Paths might become replay of messages. > > SPF policies (which are very much equivalent to SSP) > > They are completely unrelated. SPF is an SMTP protocol, not > some mail-magic like DKIM or SenderID. SPF is about the HELO > and the envelope sender, not about obscure identities like a > PRA, or the utter dubious 2822-From SSP ideas discussed here. This concern would be in regard to the initial SSP I-D. This is also where Mike and a few others appear to be headed with the requirements draft, the wrong direction. > > that are published are almost "?all", which is pretty much > > equivalent to "I sign some things" in SSP speak. > > No, an SPF PASS is still better than nothing, a bounce or any > other kind of auto-reply covered by RFCs (i.e. going to the > envelope sender) won't hit innocent bystanders. SPF FAIL and > SPF PASS both have a clear meaning wrt SMTP. Not as clear as all would want. A neutral result might lead to message acceptance, but then cause a subsequent bounce to then be dropped. This weakens the integrity of email delivery, which is the sure outcome of strict path registration without strict conformance. Never advocate strict conformance in the case of SPF however, because the SPF scripts themselves represent a serious threat. With the prevalence of malware in messages, few execute script found in messages from unauthenticated senders, however SPF requires execution of script found in DNS to obtain just authorization. SPF is ideal for taking out authoritative name servers and for causing hundred of queries for address records no one would have ever done otherwise. > > People wouldn't tolerate mail being thrown away for no good reason > > That's why it's so important to reject mail a.s.a.p. Anything > else is unreliable. SMTP is still store-and-forward in many places. Email could adopt the T10's object (content) addressable storage concept and combine that with BURL. A double hash of the object and a time stamp creates a very long token that acts as a type of password. This token is also how the storage system handles the message body at the sending side. Email changes into the rather safe exchange of URIs containing message-body tokens. At that point, there would be less need for DKIM or worrying about accepting messages. Only the Display-Name and the Subject line would be prone, and would be much easier to filter. > > nor were even the developers of SPF prepared to modify the > > way in which they forwarded email around in order to work > > around the flaws of SPF. > > That's complete rubbish. The concept of a "reverse path" is > older than RFC 821, and SPF revived it after the situation > with the broken RFC 1123 5.3.6(a) got out of hand. The same > loophole that established open relays. "Just modify RCPT TO" > never worked, it was always wrong, from day one of RFC 1123. While some were willing, the premise requires execution of scripts from anonymous senders and remains flawed. This can be fixed by associating the Return-Path with the signing-domain instead. > > There seems to be some belief that if SSP does exactly the > > same thing as SPF then we'll pull the phishing-proof, spam- > > resistant mail architecture out of the hat this time. > > A lousy chance based on PRA (SenderID). Zero chance based on > 2822-From, the concept makes no sense, it's incompatible with > tons of special cases with PRA != 2822-From. Agreed. But DKIM base can still be used to assure any originating identity without introducing the problems seen with SPF. The DOSP draft attempted to illustrate how this could be possible. There remains the mistaken belief that blocking messages after searching (often in vein) for some policy record will prevent visual spoofing. Words can not describe the futility of this effort. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
