Subject: Re: [spfbis] #33: Marked Failed Mail Exposure

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 14:25:49 -0700

At 09:26 22-08-2012, spfbis issue tracker wrote:
>#33: Marked Failed Mail Exposure
>
>  Message posted on 22 Aug 2012:
>
>  I would like to have it reopen and proposed a new 10.7 section added to
>  help implementators closed the SPF fail result security loophole.
>
>
>  10.7 Marked Failed Mail Exposure
>
>     Section 2.5.4 and 9.3.2 reinforces the local policies concept
>     that SPF receivers have no formal protocol requirement to
>     enforce rejection of mail which were detected using -ALL policies.
>     Section 2.3 highlights the domain intent and expectation for
>     such negative classification.  However, the receiver is under
>     no technical obligation to take any action for SPF failed results.
>
>     If the alternative marking is done, it is conceivable local backends
>     will still pass the mail to users with no additional red flags or
>     indicators of SPF fail. This will require more advanced MUA to
>     understand the Receive-SPF headers.
>
>     Thus under such cases, there is a possibility users can be exposed
>     to harmful mail when the backend added the Receiver-SPF but did not
>     further separate the message from the user's normal everyday mode of
>     reading/accessing mail.  For example, for POP3, the stream may need
>     to be separated and not made available for pickup.  For online access,
>     like Web-based Mail or IMAP, the backend has better control of how
>     mail is filtered, sorted, displayed and rendered.
>
>     Backends needs to take precautions of marking messages resulting
>     from SPF -ALL failed transactions but were not rejected as
>     prescribed in section 2.5.4.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html

Please review the change suggested and comment.  Scott Kitterman 
commented at http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html

Please note that Section 10 is about Security Considerations.  Please 
refer to BCP 72 for guidelines about that section.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 15:05:45 -0700

On Wed, Aug 22, 2012 at 2:25 PM, S Moonesamy <[email-masked]> wrote:
> Please review the change suggested and comment.  Scott Kitterman commented
> at http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html

I prefer no change, though I find Scott's single-sentence
counterproposal to be preferable to an entire new section.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 18:16:24 -0400

On Wednesday, August 22, 2012 02:25:49 PM S Moonesamy wrote:
> commented at
> http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html
> 

For this issue, I think it requires a two step answer:

1.  Is the issue a security issue that should be mentioned in security 
considerations

2.  If it was, what should be said about it.

I've reviewed BCP 72 and I think that the concern that is expressed falls 
within the scope of a "Message Insertion" attack as described in Section 
3.3.2.  So I think that as far as step 1 is concerned, it qualifies.

I think that the proposed addition goes into far more detail than we need, 
however.  I would propose the following alternative:

10.7  Unauthorized Message Insertion

   Section 7.1 of [RFC5321] describes security considerations associated with
   the SMTP protocol and spoofing.  SPF is an attempt to address this issue.
   When receivers deliver mail that has failed SPF checks then the affect SPF
   has on this issue is reduced.  In order to mitigate this concern it is
   important that the results of SPF check be recorded (See [Section 7]) to
   make it possible for MUAs to display message status to end users.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 16:53:48 -0700

>    make it possible for MUAs to display message status to end users.

I generally like it, but the language here doesn't acknowledge SPF's
failure modes (e.g., forwarding).  Perhaps:

s/the affect SPF has on this issue/any protection SPF offers (modulo
Section 9.2 and Section 9.3)/

...or something along those lines?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 23:15:19 -0400

>    make it possible for MUAs to display message status to end users.

This is ok, however, with two critical points.

1) We have a history of MUAs that do not qualify to do the things we 
need done and also consistently across the board, as a result backends 
has taken responsibility in much of this area.

2) We have different MUAs, Online vs Offline. There are other forms, 
i.e. mixed that 5321 touches base with with SPLIT-UI concepts, but 
overall, as an implementator of 4-6 different MUAs, they generally 
fall in two categories - online which means the backend has control 
and offline where we have a store and forward protocol for a 
time-shifted Mail Reader/Writer application.  The latter also has 
backend control and is one area that should be part of the security 
highlight.

The classic examples are dial up, telnet, IMAP, even NNTP and web-mail 
and others for online and POP3, QWK, FIDONET etc  for offline.  I 
tried to KISS this with the two sentences I had:

    ......   For example, for POP3, the stream may need
    to be separated and not made available for pickup.  For online access,
    like Web-based Mail or IMAP, the backend has better control of how
    mail is filtered, sorted, displayed and rendered.

Another way to look at it, is that SPF is more for the backend than 
for the OFFLINE MUA.

I can understand how in practice we tend to lump the "MUA" as one idea 
for all types, but that is where we get into trouble sometimes in 
generalization and we never do much for the MUA concepts.  I think we 
can preempt that by simply highlighting there are different ways to 
access mail and we can only really talk about standard protocols like 
POP3, IMAP, even NNTP but also perhaps the common understood method we 
call WebMail which is generally a proprietary access format.  Perhaps 
a better ending sentence may be to use MFA (Mail Filtering Agent) 
along with MUA.

     ... to make it possible for MFA (Mail Filtering Agents) to separate
     mail storage streams, i.e. Junk MailBoxes/Filters, etc, and for
     advanced MUAs to display message status to end users.

I prefer to use term "advanced" with MUAs because not all offline mail 
readers have the extra RBM (Rule Based Messaging) technology (btw, 
once patented - expired years ago) and some MUAs presume and rely on 
the backend not passing the junk anyway.  The latter is where POP3 
comes into play because that is one single stream from the backend. 
IMAP, NNTP are multiple streams protocols where  you can have 
separation at the backend.  But as indicated about, one goal is to 
highlight that pop3 mail pickup does not get the SPF failed mail for 
example.  I believe I mentioned that with HOTMAIL.COM, I had forced a 
SPF FAIL message and it was junk mail saved only viewable online only. 
  Via POP3, I didn't get it.

We can easily run a few test here at various ESPs that purportedly 
support SPF using manual TELNET port 25 transactions, using a spoofed 
MAIL FROM from a domain that has a -ALL policy.

Let me try it at gmail.com using a facebook.com return path with a 
RCPT TO: to my gmail account.....

                    --------------------------
220 mx.google.com ESMTP g67si5696422yhk.95
EHLO LOCALHOST
250-mx.google.com at your service, [208.247.131.8]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
MAIL FROM:<[email-masked]>
250 2.1.0 OK g67si5696422yhk.95
RCPT TO:<[email-masked]>
250 2.1.5 OK g67si5696422yhk.95
DATA
354  Go ahead g67si5696422yhk.95
Date: Wed, 22 Aug 2012 17:51:33 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc. TEST MESSAGE
MIME-Version: 1.0
To: [email-masked]
Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF

Test of the american broadcasting system
.
250 2.0.0 OK 1345690848 g67si5696422yhk.95
quit
221 2.0.0 closing connection g67si5696422yhk.95

Connection to host lost.
                    --------------------------

Now checking my [email-masked] account....

It was placed in a SPAM BOX with this notification at the top of the 
basic header display:

       Why is this message in Spam? It's similar to messages that were 
detected
       by our spam filters. Learn more

and viewing the original message headers shows the two trace lines:

Received-SPF: fail (google.com: domain of [email-masked] 
does not designate 208.247.131.8 as permitted sender) 
client-ip=208.247.131.8;
Authentication-Results: mx.google.com; spf=hardfail (google.com: 
domain of [email-masked] does not designate 208.247.131.8 
as permitted sender) smtp.mail=[email-masked]

This is exact behavior we want for a accept/mark mode of operation.

But keep in mind this is online access.  I believe the goal is to add 
the highlight regarding POP3 access and that its recommended it should 
not be part of the normal pop3 mail pick up.  In most cases, it will 
naturally be the case because the backend already separated the stream 
and I believe (without actually do it) if I used a POP3 access to 
gmail.com (and I don't recall if they do offer it), I would not get 
the spoofed message.  However, via IMAP access, I see it in the spam 
folder using my Thunderbird.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 23:31:40 -0400

> RCPT TO: to my gmail account.....

SPF is an MTA to MTA protocol.  I don't think it's appropriate to include an 
MUA design missive in the security considerations.  I think it's enough to 
document the consideration and let MUA designers deal with it appropriately.  
If you look at RFC 5451 Section 7.1 there is some discussion about similar 
concerns for authentication-results header fields.  This can get very 
complicated very quickly and should, if more detail really needs to be 
standarized, done in a different document as it's a different problem.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Aug 2012 00:01:03 -0400

Maybe I am not reading you right. Are you agreeing that the SPF trace 
lines is more for the backend (MDA) then for the MUAs?

Separation is the key here for the security note and that will 
basically remove the MUA factor or rather move the ergonomics to the 
MUA (spam boxes, showing notifiers, etc). Overall, we can never depend 
on MUAs and there is different types.

Consider that a MDA that does not have "Spam Folders" for users, they 
are at a higher risk when using ACCEPT+MARK mode that is 100% resolved 
by using as REJECT mode.

Separation for Accept/Mark - that is all the point is about the 
security note of my posted issue.  Its not a mandate for design, its a 
security note implementators need to be aware off.

Scott Kitterman wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Aug 2012 00:03:08 -0400

> ...or something along those lines?

I think it's the other way around.  Those failure modes are reasons why 
someone might choose not to reject at SMTP time, but they aren't part of this 
issue, I don't think.  

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Aug 2012 00:26:50 -0400

> security note implementators need to be aware off.
...
If the goal is something user visible, it has to carry to the MDA and through 
to the MUA.  I don't think we can or should mandate MUA design to include SPF 
specific indicators.  I think my proposed note captures the issue that needs to 
be considered by MDA/MUA developers and administrators.  Do you disagree?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 23 Aug 2012 20:07:20 +0200

On Thu 23/Aug/2012 06:03:08 +0200 Scott Kitterman wrote:
>>>    Section 7.1 of [RFC5321] describes security considerations associated
>>>    with the SMTP protocol and spoofing.  SPF is an attempt to address this
>>>    issue.  When receivers deliver mail that has failed SPF checks then the
>>>    affect SPF has on this issue is reduced.  In order to mitigate this
>>>    concern it is important that the results of SPF check be recorded (See
>>>    [Section 7]) to make it possible for MUAs to display message status to
>>>    end users.
>>

I'd s/MUAs/downstream message processors, such as MUAs,/.  It goes
without saying that they have to be prepared to receive a stream of
messages not so clean as it could be, doesn't it?

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 21:56:37 -0700

>1.  Is the issue a security issue that should be mentioned in security

Could working group participants please review the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html for 
information about Issue #33 and comment on the above question?

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 05:25:38 -0000

Close it.  This proposal is totally ill-advised.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Aug 2012 22:39:20 -0700

> Close it.  This proposal is totally ill-advised.

I would agree, except Scott's discovery of recommendations for
security considerations makes me think the IESG could reasonably
expect something like this.  In that case, I prefer his one-paragraph
response.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 02:13:26 -0400

> information about Issue #33 and comment on the above question?

4408/BIS offers a mode of operation for -ALL that is not a rejection, 
but accept+marking the message.  This negates the intent of the domain 
to negatively treating the message with an RFC2119 MUST requirement of 
using -ALL.  If the SPF receiver backend does not separate this 
accept+marked message,

   a) the user is now at risk of receiving harmful mail deemed
       unauthorized by the domain owner,

   b) the domain reputation is potentially harmed,

   c) the receiver abuse is increased.

If section 2.5.4 does not provide the semantically equivalent 
rejection form of accept+marking the message, then we have a security 
loophole and issue and it needs to be mentioned in the security 
consideration section.

In addition, to not consider it a security issue, the accept+marking 
mode for SPF failed results presumes a backend mail design where mail 
separation already exist.

Either way, the concept of separation for failed messages need to be 
described in 4408BIS to make implementators aware of the situation.

-- 
HLS

---

From: Commerco WebMaster <[email-masked]>
Date: Fri, 24 Aug 2012 00:21:24 -0600

> information about Issue #33 and comment on the above question?

The spirit and intent of the text seems correct.

Remembering that a primary goal for SPF is to protect a domain holder's 
domain reputation when a third party uses the domain name without the 
domain holder's permission, perhaps an easier way to express that spirit 
and intent might look like this:

----
When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record 
and the result of a receiver MTA's SPF processing is an SPF FAIL, the 
receiving MTA (or any downline MTAs to which it or its successive 
forwarders must forward messages by reason of the receiver's local 
policy [e.g., downstream antispam analysis machines, DMARC implementers, 
etc.]) MUST NOT allow the message to ever reach the MUA(s) of the final 
RCPT TO address(es) in the message under any circumstance (i.e., the 
final mail recipients MUST NOT ever receive messages which fail SPF -ALL 
processing), nor should such -ALL SPF FAIL messages ever be used to 
impugn the reputation of the domain publisher.
----

I think that the above leaves very little to the imagination as to what 
the publisher intended in implementing SPF, while simultaneously 
allowing a receiver a huge amount of latitude as to what they can do 
with the messages (pretty much anything) as long as they don't deliver 
the failed SPF -ALL message to the end point receiver(s) or cause 
reputation harm to come to the SPF publisher's domain reputation from a 
failed SPF -ALL message event.

Alan M

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Aug 2012 23:50:23 -0700

Alan,

On Thu, Aug 23, 2012 at 11:21 PM, Commerco WebMaster
<[email-masked]> wrote:
> When an SPF publisher employs the -ALL syntax in a DNS SPF TXT record and
> the result of a receiver MTA's SPF processing is an SPF FAIL, the receiving
> MTA (or any downline MTAs to which it or its successive forwarders must
> forward messages by reason of the receiver's local policy [e.g., downstream
> antispam analysis machines, DMARC implementers, etc.]) MUST NOT allow the
> message to ever reach the MUA(s) of the final RCPT TO address(es) in the
> message under any circumstance (i.e., the final mail recipients MUST NOT
> ever receive messages which fail SPF -ALL processing), nor should such -ALL
> SPF FAIL messages ever be used to impugn the reputation of the domain
> publisher.

This flies in the face of all of the discussion about SPF being input
to a larger message evaluation system and basically says that SPF
"fail" wins over everything.  Even RFC4408 didn't go that far.  It
gives no consideration to false negatives, which is the main reason
lots of operators don't treat a fail with "-all" as gospel already.
It doesn't even permit delivery to spam folders in that instance.

-1 from me.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 03:24:20 -0400

> "fail" wins over everything.  Even RFC4408 didn't go that far. 

RFC4408 section 2.5.4:

    A "fail" result is an explicit statement that the client is not
    authorized to use the domain in the given identity.  The checking
    software can choose to mark the mail based on this or to reject the
    mail outright.

No other factors or additional add-on message eval system technology 
required.

Reject the mail outright is the easiest solution.  Accepting and 
marking the mail is a much more complex implementation concept which 
may begin to support advanced msg eval systems you speak of, however, 
in lieu of it, we have a security issue implementations need to have 
design insights for.

What is the harm in this security consideration?

-- 
HLS

---

From: Commerco WebMaster <[email-masked]>
Date: Fri, 24 Aug 2012 01:59:46 -0600

Murray,
> It doesn't even permit delivery to spam folders in that instance.

I think that I can understand why you might feel that way, however, SPF 
does allow other options for publishers who wish to use it in a less 
publisher centric absolute manner (e.g., ~ALL).

Obviously some folks do and will get their configurations wrong, but is 
it really the role of a standards group working on a standards draft to 
account for every misconfiguration (unintended or otherwise) in a 
standard?

In other words, the punishment for publisher misconfiguration perhaps 
should be that things won't tend to work very well for the publisher 
with incorrectly configured SPF TXT records.  Generally, that sort of 
thing is almost always adequate to get folks to fix their published records.

I suppose my view comes from the publishers standpoint, in that I became 
a proponent of SPF all those years back specifically because it featured 
a real method to absolutely confirm that a published domain can 
absolutely be scored as, "if you received a message from our domain, it 
was not authorized and you should know it did not come from here" - in 
other words:

"v=spf1 -all"

A receiving MTA should toss anything coming in that way from a domain 
publishing the above.  If the publisher wants to get feedback, I believe 
that our editor, Scott Kitterman, has a nice RFC out there to handle that.

Or, if I specify that only certain machine IPs are allowed to send mail 
for a given domain through publishing an SPF TXT record for the domain 
and the receiving MTA finds that the sending MTA is not in that IP set, 
I can depend upon the mail to not get through.  That is part of the 
overall appeal for SPF publishers, at least this one, as it protects the 
reputation of a domain, by respecting the intent of the domain holder 
who publishes a -ALL style SPF TXT record for the domain under their 
control.

Put simply, in publishing with -ALL, I would rather not have some 
interpretive algorithm attempting to understand my intent as a SPF 
publisher.  Instead, I'd prefer a receiver to just simply respect the 
-ALL and go from there.

If a receiving MTA Fails in a -ALL, it should return something to the 
sender about their not being allowed (e.g. a 5xx error of some kind as I 
recall).  If there is an SPF publisher misconfiguration, then logically, 
the sender should see it as a function of their MTA being told "no" by 
the receiver.

I am completely okay with ~ALL implementations being subjected to 
whatever receiver "interpretation of intent" receivers may choose to do, 
however I think that -ALL really should be an absolute expression of a 
domain holder SPF publisher's will, where it comes to an -ALL SPF "fail" 
and receivers should respect that publisher's will.

Alan M

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 24 Aug 2012 11:18:37 +0200

> expect something like this.  In that case, I prefer his one-paragraph

+1, however ill-advised the assumption that a downstream agent might
know better.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 24 Aug 2012 12:28:57 +0200

> publisher.  Instead, I'd prefer a receiver to just simply respect the

The protocol delivers a result for a given input.  A result of "fail"
is "fail", irrespectively of which mechanism yielded that result.
Bullet 1, part 1, Section 9.2.2 of the current I-D gives an example
where one can get a "fail" with ?all:

   "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"

I don't think that a failure originating from there should be treated
any differently than one resulting from a -ALL.

That said, SPF aims at domain name abuse, and allows legitimate
forwarding.  It considers a forwarding to be legitimate when it occurs
either on the sender's or on the receiver's side.  It doesn't take
into account "spontaneous" forwarding, from a mailbox to another one
without advice.  That's illegal in many countries,  but privacy laws
provided no protocol to ease abiding by them.  Nevertheless, we have
to cope with that.

While respecting the intent of the domain holder, a receiver can
recognize that a sender is (temporarily) part of its network, inasmuch
as it is relaying a good message --thereby promoting the use of
receiver's services in preference of its own ones.  That's what
receiver policies are all about.

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 17:38:29 -0000

>impugn the reputation of the domain publisher.

No.  This proposal is equally ill-advised.

SPF is about defining a way for mail-sending domains to publish
policies about sending hosts, and for recipient systems to find out
what a domain's policy is about a particular host.

It is most definitely not about MUA design, or what a recipient
system does with the policy information it has available.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 17:39:57 -0000

>publishing the above. ...

No.  This specific proposal has been rejected innumerable times in the
past.  I cannot imagine why anyone would bring it up yet again.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Aug 2012 10:41:43 -0700

On Fri, Aug 24, 2012 at 12:59 AM, Commerco WebMaster
<[email-masked]> wrote:
> I think that I can understand why you might feel that way, however, SPF does
> allow other options for publishers who wish to use it in a less publisher
> centric absolute manner (e.g., ~ALL).
>
> Obviously some folks do and will get their configurations wrong, but is it
> really the role of a standards group working on a standards draft to account
> for every misconfiguration (unintended or otherwise) in a standard?

Of course not, but it is also not the place of a standard to disregard
obvious failure modes, especially when those involve third parties not
involved in the protocol.  Some examples come to mind:

User A sends to user B, who has forwarding arranged to address C.
Said forwarding leaves the envelope sender unmodified. Upon receipt at
C, SPF evaluation is performed.  Of course, the MTA at B is not
authorized to send mail for A, so SPF fails and the message bounces.
Under your vision for SPF, in essence, A must ensure that it will
never send mail to anyone that might set up mail forwarding.  I
suggest that's an unreasonable burden.

User A sends to list B, which relays to C (among others, as C is
subscribed) without changing the envelope.  (Historically, some MLMs
acted that way.)  B observes the bounce, and ultimately unsubscribes C
as a bad address.  C, whose only crime is to participate in SPF and
subscribe to list B, is now kicked off the list through no fault of
its own.  (This scenario is admittedly much more visible under ADSP.)
The only way to avoid this is to ensure that nobody at A ever
subscribes to a list.  I suggest that's also unreasonable.  There are
many companies that solve this by having one domain for users and a
different domain for critical transactional stuff, but most of them
dislike having to do that.

User A sends to B which forwards to C.  C rejects due to SPF failure.
B is doing the forwarding inline, so it also rejects.  A now thinks B
is a bogus address when in fact it is not.  This is a variant of the
first case, which means A can't ever send mail to anyone that
forwards.

The notion of demanding that fail + -all = reject also contradicts
some well established principles that local policy is local policy and
cannot be legislated by any standards action; it belongs solely to the
ADMD.

Moreover, given two receivers, one of whom does strict "-all"
rejection and one that is softer and has a wider evaluation policy,
people will vote with their feet when one of these failure modes hits
on legitimate mail and move to the more comprehensive policy provider.
 (The more strict site will be perceived as "broken".)  It then
becomes a business decision not to be strict regardless of what's in
the protocol.  (Admittedly, this is also why there's very weak
enforcement of mail format standards, but that's for another
discussion.)

The protocol has to accept such realities.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Aug 2012 10:57:15 -0700

> document the consideration and let MUA designers deal with it appropriately.  

+1.  Very nicely stated.

In fact, I think that putting the sentence "SPF is an MTA to MTA
protocol." into the document -- probably Intro -- would be useful.

d/

-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Aug 2012 11:02:55 -0700

> expect something like this.  In that case, I prefer his one-paragraph

+1

d/

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 14:08:01 -0400

It was repeated numerous times that the BACKEND needs to do the 
separation and how the MUA does would need to be VERY ADVANCED to deal 
with the situation and we could not depend on the MUA to solve this 
issue.    Please read the proposal better.  Thanks.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 14:46:14 -0400

These are similar to old arguments since MARID that has failed to gain 
traction and were  rejected as reasons to not explore the fast entry 
SPF protocol.

As Alan now and many has stated since 2005 if a domain is unsure of 
its outbound mail senders and its "associates", then it needs have a 
more relaxed domain SPF policy.  It is not a candidate to use a strong 
-ALL hard fail policy, nor should it expect that a receiver would be 
using one of those kludged methods like SRS to resolve any false 
positive issues with forwarding.

This is why SPF offers the more relaxed policies of SoftFail (~ALL) 
and Neutral (?ALL) which does require additional factors to make any 
conclusions about the the transaction.

The thing is over time, domains has learned. Many that did begin with 
a relaxed policy have found continued spoofing problems and have 
switched to the hard fail (-ALL).

The point is -ALL has a special meaning described in 2.3.  There is a 
certain intent and expectation.  2.5.4 offers a REJECT and a 
ACCEPT+MARK mode of handling.  This issue/topic is how  ACCEPT+MARK 
can be harmful when its not semantically equivalent to the REJECT mode 
of operation.

The BACKEND is the only possible part of the framework that can deal 
with this.  The MUA can not deal with this.  It can, in theory, but it 
needs to be advanced and much trust is required by the user.

The backend is the only practical method of dealing with this issue.

-- 
HLS

---

From: SM <[email-masked]>
Date: Fri, 24 Aug 2012 12:01:08 -0700

>is "fail", irrespectively of which mechanism yielded that result.

I would like to proceed with the above as a starting point.  The 
questions to the working group are:

   (a) Is there an issue where malicious content can be delivered to
       the recipient when there is a SPF "Fail" [1]?

   (b) Is there an issue where malicious content can be delivered to
       the recipient when there is a SPF "Pass" [2]?

Regards,
S. Moonesamy
SPFBIS WG -co-chair

1. A "Fail" result is an explicit statement that the client is not 
authorized to use the domain in the given identity.

2. A "Pass" result means that the client is authorized to inject mail 
with the given identity.

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 15:02:17 -0400

>> document the consideration and let MUA designers deal with it appropriately.  

For the record, the proposal IS NOT asking that MUA resolves the 
security issued with accepted marked failed messages.  It clearly 
states the backends need to take precaution  to address this without 
getting into any specific methods or mandate.

> protocol." into the document -- probably Intro -- would be useful.

I am not to sure about that.

SPF is more of a MTA to MDA protocol.

We already have technology to deal with MTA to MTA transports to 
address open relay problems.  We use ESMTP AUTH, IP Relay 
Authorizations, POP3 BEFORE SMTP and maybe others prearranged MTA to 
MTA transports.

But at the MDA, there is no more further relay expected.  No 
authentication is required for the final local mail recipients (unless 
we are using the SUBMIT protocol - port 587).   This is where the 
spoofing begins with the bounce problems and SPF comes into play to 
help mitigate the problem.

-- 
HLS

---

From: Commerco WebMaster <[email-masked]>
Date: Fri, 24 Aug 2012 14:12:24 -0600

John,
> what a domain's policy is about a particular host.

Absolutely correct.  What I am trying to suggest in the above is that 
the recipient systems should respect the published policies of the 
sending hosts when there is 100% certainty about the interpretation of 
the published SPF DNS TXT record for a domain.

Certainly in basic situations like "v=spf1 -all", the intent is always 
that "the domain you asked about does not send email".  Changing that to 
be anything other than what that it really is seems wrong.

> system does with the policy information it has available.

Again, absolutely agree.  My wording was deliberate to allow for the 
possibility of a pass through for an SPF -ALL "Fail" as long as the MTAs 
always do two things.

1 The MTAs receiving a forwarded "Fail" message must never allow a MUA 
to get hold of such a message.

2 The MTAs which receive the message never use a "Fail" message to 
create a problem for a domain's reputation.

I suggest that if in the "v=spf1 -all" example, failing to do either of 
the above if the original receiver passes along an SPF "Fail" seems 
rather unfair to an SPF publisher and sort of defeats the point or at 
least diminishes the value in a domain holder publishing an SPF record 
using the -ALL syntax.

> John

Best,

Alan M

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 20:14:24 -0000

>the published SPF DNS TXT record for a domain.

We've already said no to this proposal about a hundred times over the
history of this WG and its predecessors.  Do we really have to say no
a hundred times more?

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Aug 2012 16:21:15 -0400

<hat type="dnscrank">

On Fri, Aug 24, 2012 at 02:12:24PM -0600, Commerco WebMaster wrote:

> the sending hosts when there is 100% certainty about the
> interpretation of the published SPF DNS TXT record for a domain.

This condition can never be met.  Since it's a TXT record, you can't
be sure that it's intended for use with SPF, so 100% certainty is impossible.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Commerco WebMaster <[email-masked]>
Date: Fri, 24 Aug 2012 14:53:54 -0600

Murray,

> suggest that's an unreasonable burden.

Agreed.  There has also been discussion over the years for how using 
SPF, in some limited forwarding situations, has some arguably show 
stopping issues for some publishers under the -ALL syntax.

That said, SPF is not and has never presented itself as a final solution 
for all email scenarios.  SPF does work well for "well behaved" MLMs and 
direct MTA to MTA mail transfers.  It also seems to work well from 
around 7 years of experience in general use.

If a publisher plans to have forwarding in their environment by user 
demand or as a market driven decision, perhaps the ~ALL syntax is better 
for them.

Alternatively, perhaps this discussion should be taking place for a 
future SPF3 spec, where we could look at such things as an additional 
parameter for relaxed forwarding, such that a publisher can indicate 
they would prefer such an arrangement to allow for what you present in 
the hypothetical example above within the -ALL syntax.

Or perhaps allow for a new way to indicate an absolute statement of 
publisher's will and intent, as I suspect many publishers believed was 
the case with -ALL when they first came to SPF.

> dislike having to do that.

Again, agreed this is a valid example, but as before, SPF cannot stop 
folks from representing themselves as something they are not and then go 
back and say, well, maybe they are okay after all.  As you point out, 
the idea of a mailing list doing such things did (and probably still 
does happen), but then they really should not be misrepresenting 
themselves as something they are not or again, the publisher might be 
forced to use the ~ALL syntax if the list owner refuses to repair their 
MLM software's behavior.

> first case, which means A can't ever send mail to anyone that

Well, perhaps.  If B has checked SPF and found A as valid, it should 
never conclude that the address from A was bogus by virtue of a bounce 
from C.

Of course such things do happen in the wild.  But, I think that the 
entire idea behind SPF white lists was to avoid or at least negate that 
sort of scenario.

> cannot be legislated by any standards action; it belongs solely to the

Indeed, local policy is local policy and SPF was designed to 
successfully be interoperable with MTAs which never understood or used 
SPF.  The argument you make is real, but it also goes back to why SPF 
was so widely adopted by publishers.

That is, domain holders finally saw a workable way to be able to combat 
folks misusing their domain names in spam email messages by publishing 
their domains as being tied to specific authorized sending MTAs.  I 
think that publishers saw -ALL as being a way to make an absolute 
declaration of will as regards the treatment of their domain names in 
email messages.

Granted, in the real world there are certainly some issues with 
forwarding and, to a lesser extent mailing lists, but having lived with 
SPF since 2005, there have been very few issues we could not address 
with SPF TXT records.  In fact, we found ways to address all the issues 
we have encountered with SPF here in one way or another.

> enforcement of mail format standards, but that's for another

I agree and understand.  Again, perhaps this is a discussion for a 
future SPF3 spec where a syntax might be developed to allow smaller MTAs 
to differentiate themselves from the needs of larger commercial 
enterprises, where there are certainly wider scopes for implementations 
that the smaller enterprises do not face.

> The protocol has to accept such realities.

Agreed, although it should also be able to be scalable and responsive to 
the needs of all implementers from the smallest to the largest.

Best,

Alan M

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Aug 2012 17:22:30 -0400

>least diminishes the value in a domain holder publishing an SPF record 

Yes, but the "S" in SPF stands for sender, not receiver.  Trying to specify what actions receivers should take would be completely novel in 4408bis. The goal of this bis exercise is to get through it with a minimum of novelty.

Rehashing the (intentional) lack of specified receiver policies in 4408, and thus also 4408bis isn't helping.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 20:13:38 -0400

> Rehashing the (intentional) lack of specified receiver policies in 4408, and thus also 4408bis isn't helping.

I don't see it as rehashing. Just serving reminder of its original 
purpose and intent with the new reinforcing that ACCEPT+MARK is 
actually more popular that one may otherwise believe.

It takes two to tango in client/server protocol. The S in SPF may be 
"Sender" (client) but it means nothing without a Receiver (server).

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 25 Aug 2012 12:16:35 +0200

On Fri 24/Aug/2012 22:53:54 +0200 Commerco WebMaster wrote:
>> Said forwarding leaves the envelope sender unmodified. [...]
> 
> demand or as a market driven decision, perhaps the ~ALL syntax is
> better for them.

B forwards on its own, without telling to A, let alone following its
plans.

> never conclude that the address from A was bogus by virtue of a bounce

The problem is with the original poster A, not B.

A newly added paragraph introduces check-before-forward semantics:
(part 2, bullet 3, of Section 9.2.2
http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06#section-9.2.2
BTW, how about having sub-subsections for those parts?)

User A sends to B.  B has a forwarding "recipe" to C, but it checks
SPF as if it were C before doing so.  That way, B finds that, if it
forwards the message, C will compute a "fail" for it.  Then, rather
than replying 251 to the RCPT command, it replies 551 to reject it.
The author gets a bounce notifying the change of address at B.

If B and C have no special relationship with A, the SPF check from C's
POV that B carried out is similar to the SPF check from D's POV that C
would carry out in a more involved case A -> B -> C -> D where B
accepted the message.  In the latter case, C can reject with 551, and
B can send a bounce because it had an SPF "pass" from A.

I propose to grant full citizenship to this technique by introducing
it somewhere in Section 2.  It requires an extra check_host()
evaluation, with different input.  Although it can be considered a
change, it is fully backward compatible, so I think it's feasible if
the WG agrees on it.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 26 Aug 2012 22:15:28 -0700

Hello,

This is a rough summary of Issue #33.

Scott Kitterman mentioned [1] that SPF is an MTA to MTA 
protocol.  (He doesn't) think it's appropriate to include an MUA 
design missive in the security considerations.  Alessandro Vesely 
commented [2] that it goes without saying that they have to be 
prepared to receive a stream of messages not so clean as it could be, 
doesn't it?  Murray Kucherawy mentioned that he supported the text 
suggested by Scott Kitterman [10] as the IESG could reasonably expect 
something like this [3].

Hector Santos commented that 4408/BIS offers a mode of operation for 
-ALL that is not a rejection, but accept+marking the message [4].  He 
also mentioned that if the SPF receiver backend does not separate 
this accept+marked message, the user is now at risk of receiving 
harmful mail deemed unauthorized by the domain owner.  Commerco 
WebMaster mentioned that a primary goal for SPF is to protect a 
domain holder's domain reputation when a third party uses the domain 
name without the domain holder's permission [5].  Hector Santos asked
what is the harm in this security consideration? [6]

Alessandro Vesely commented that the protocol delivers a result for a 
given input.  A result of "fail" is "fail", irrespectively of which 
mechanism yielded that result [7].  John Levine pointed out that 
(SPF) is most definitely not about MUA design [8].  Hector Santos 
mentioned that SPF is more of a MTA to MDA protocol [9].

As an individual comment, I will err on the side of caution and 
assume that there is a security issue.  I read the test case provided 
in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02246.html 
The result of the SPF processing was:

   Received-SPF: fail (google.com: domain of testuser at facebookmail.com
   does not designate 208.247.131.8 as permitted sender) 
client-ip=208.247.131.8;
   Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of
   testuser at facebookmail.com does not designate 208.247.131.8 as permitted
   sender) smtp.mail=testuser at facebookmail.com

And the comments from the WG participant were:

   "Now checking my sant9442 at gmail.com account....
    It was placed in a SPAM BOX with this notification at the top of the basic
    header display:

    Why is this message in Spam? It's similar to messages that were detected
    by our spam filters."

And:

   "This is exact behavior we want for a accept/mark mode of operation."

The Security Considerations section of a document is to discuss the following:

    - which attacks are out of scope (and why!)
    - which attacks are in-scope
      *  and the protocol is susceptible to
      *  and the protocol protects against

I would be concerned if a security consideration is used to promote a 
particular behavior instead of addressing an attack.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02247.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02283.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02294.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02295.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02296.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02298.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02303.html
8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02305.html
9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02320.html
10. http://www.ietf.org/mail-archive/web/spfbis/current/msg02230.html