Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities

From: Stuart Gathman <[email-masked]>
Date: Wed, 04 Apr 2012 02:28:50 -0400

Long ago, Nostradamus foresaw that on 03/25/2012 06:14 AM, Alessandro
Vesely would write:
> Until we hold that reject-on-fail is valid, SPF is less optional than
> it would seem at a first glance, because it affects a mail operation
> that used to be possible without it. A sender who does not opt for SPF
> can have its forwarded messages bounced because both the originator
> and the target opted to implement SPF in such a way to break that
> operation. In this respect, SPF has changed SMTP already, whether
> we're gonna document that as an update or not. What's worse is that
> there's no guidance on how to avoid such incidents. A protocol worth
> its salt should allow to determine what parties are at fault in case
> of malfunction.
If by "sender" you mean an alias forwarder, then there are three cases:

a) the alias forwarding was requested/authorized by the target.  In this
case, the target screwed up by trying to apply SPF to the forwarder, who
has now become a "border MTA" of the target in the language of rfc4408.

b) the alias forwarding was requested/authorized by the sender.  In this
case, the sender screwed up by failing to include the forwarder (who has
now become a "border MTA" for the sender) in their Sender Policy.

c) the alias forwarding was *not* authorized by the sender or target. 
In this case, the "forwarder" is a forger and SHOULD be rejected.

In brief, an alias forwarder is either an agent of the sender - and
therefore a border MTA of the sender, or an agent of the target - and
therefore a border MTA of the target, or illegitimate. 

There is no forwarding problem.  Only broken SPF records with sender
authorized alias forwarders, or broken implementations for receiver
authorized alias forwarders.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Apr 2012 17:22:59 +0200

On 04/Apr/12 08:28 +0200, Stuart Gathman wrote:
> that on 03/25/2012 06:14 AM, Alessandro Vesely would write:

Cases (a) and (b) are not a problem.  They imply cooperation between
the relevant domains.  They are a small niche.

> In this case, the "forwarder" is a forger and SHOULD be rejected.

False, this case includes legitimate forwarders.  People who work in
an organization may sport an email address that reflects their
affiliation.  Email facilities at that organization's site may include
the ability to set a forward address.  Users may choose a different
mail site for its interface, its filtering, or whatever other reason.
 It is not uncommon to have users forwarding to gmail, and from there
to yahoo, and possibly more.

At policy-making time, an organization may opt for not changing the
bounce address on forwarding.  Since that's what the standard says,
they may consider it good behavior to do it that way.  Indeed, it can
result in due NDNs in some cases.  Asking authorizations for each
forward address is not practical.

> authorized alias forwarders.

Why don't you try and define a proper TXT RR at _dmarc.gathman.org and
see what you get?  Discussing possible solutions may be more
productive than negating that the problem exists.

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 04 Apr 2012 15:26:10 -0400

Long ago, Nostradamus foresaw that on 04/04/2012 11:22 AM, Alessandro 
> to yahoo, and possibly more.
The situations you just described are *authorized* forwarding, so it is 
case b.  I repeat, unauthorized forwarding is forgery and should be 
rejected.  *If* a recipient wants to check SPF, then their 
implementation must take into account authorized forwarders as described 
in rfc4408 section 9, esp 9.5.  A recipient authorized forwarder is a 
"border MTA" of the recipient.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 05 Apr 2012 19:50:52 +0200

On Thu 05/Apr/2012 19:26:19 +0200 Stuart D Gathman wrote:
> that on 04/04/2012 11:22 AM, Alessandro Vesely would write:
>>
> The situations you just described are *authorized* forwarding, so it
> is case b.

I don't see how.  You described case (b) as:

   b) the alias forwarding was requested/authorized by the sender.
      In this case, the sender screwed up by failing to include the
      forwarder (who has now become a "border MTA" for the sender) in
      their Sender Policy.

I was talking about generic dot-forward files, whereby they forward
any message, irrespectively of the sender, to whatever external
addresses the users configured their forwarding recipe with.

> I repeat, unauthorized forwarding is forgery and should be rejected.

They configure forwarding recipes through web forms.  Nobody is going
to ask and obtain authorizations, and have SPF records updated.

> *If* a recipient wants to check SPF, then their implementation must
> take into account authorized forwarders as described in rfc4408
> section 9, esp 9.5.  A recipient authorized forwarder is a "border
> MTA" of the recipient.

Keeping in mind that relaying should be authorized on a per-user
basis, the only way to do that consistently, AFAICS, would be that
each organization maintains a user+forward whitelist of granted
authorizations.  Records in such whitelists are inserted after a
trusted request of forwarding, presumably performed by web2 means in
the server part of the web form that users configure forwarding with.
Then, the whitelists are referred from SPF records, using local macros
as appropriate.  That is SMTP-fictional, IMHO.

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Apr 2012 15:05:46 -0400

Hi,

In my view, there are 3-4 SPFBIS clarifications that should be made:

  1) Clarification of when SPF verification starts and ends,

     1.1) For Client Machine Domain :: IP checks
     1.2) For Return Path Domain :: IP checks

  2) Clarification of the compliant SPF client expectation to conform 
to the
     RFC5321 validity of a EHLO/HELO client domain name (CDN),

  3) Clarification of when EHLO/HELO client domain name and Return Path
     Domain SPF verification together or separately applies, or even
     delayed until the Forwarding Address is known or deemed valid, and

  4) Clarification on how much a domain needs to protect its domain
     at the client machine level and/or return path level, which can
     have a direct and indirect affect on #1, #2 and #3.

I believe you are proposing #2 and #4 in issue #12 and it appears 
Stuart is referring to #1

By design, SPF is a single hop, direct to MDA protocol where the 
sender connecting IP is associated with the public client machine name 
or domain literal and/or the persistent SMTP return path domain.  IMV, 
anything going beyond this with sender forwarding methods and changing 
the return path domain is beyond the scope of SPF, or rather what SPF 
Domain can not expect to occur.  The protection is only for first hop.

One of the main concerns I always had with SPF is its high waste DNS 
factor and a prudent implementation SHOULD look at the entire scope of 
SMTP process parameters for its check_host() function:

    CIP - client connection IP
    CDN - client domain name (EHLO/HELO)
    RPD - sender return path (MAIL FROM)
    FPA - forwarding path address (RCPT TO)

SPFBIS should refer to RFC5321 section 3.3 which provides validation 
and optimization recommendations:

    3.3 Mail Transactions

    .....

    Despite the apparent scope of this requirement, there are
    circumstances in which the acceptability of the reverse-path may
    not be determined until one or more forward-paths (in RCPT
    commands) can be examined.  In those cases, the server MAY
    reasonably accept the reverse-path (with a 250 reply) and then
    report problems after the forward-paths are received and
    examined.  Normally, failures produce 550 or 553 replies.

For systems under a typical anonymous attack of spammers and spoofers, 
a high failure rate of RCPT TO unknowns provide a short-circuiting of 
SPF DNS waste for the client domain and/or return path domain.  For 
nearly 9 years, we have see a near consistent 60% RCPT TO failure, 
thus this would correspond to a 60% reduction in SPF DNS overhead.

So while its important to recommend SMTP client to conform to RFC5321 
valid client domain names and possibly protect the public client 
domain with SPF,  there will be an higher DNS waste with the SPF 
receiver performing this action.  So it SHOULD have some SPFBIS 
empirical learned intelligence in the validity of all the SMTP 
transaction parameters before performing SPF checking.

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 15:10:59 +0200

On Fri 06/Apr/2012 11:29:10 +0200 Hector Santos wrote:
>     to the RFC5321 validity of a EHLO/HELO client domain name (CDN),
> 

It may well be so.  Let me clarify by example:  Google doesn't check
the helo identity, so a type (c) forward to gmail would get an SPF
fail.  That is good, as long as gmail does not reject on fail.

RFC 4408 says, in 2.4. Checking Authorization:

            At least the "MAIL FROM" identity MUST be checked, but it
   is RECOMMENDED that the "HELO" identity also be checked beforehand.

And then, in 2.5.4. Fail, it substantially says that reject-on-fail
gets triggered in such case.  (BTW, let me note once more that the
need to pretend not to mandate receiver's behavior forces an unclear
language in this an similar RFCs.  See next message.)

The error correction that I'm proposing with issue #12 substantially
is that the helo identity must be checked by those who do reject-on-
fail, and if it is a "pass" the receiver must not reject.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Apr 2012 09:31:24 -0400

> fail, and if it is a "pass" the receiver must not reject.

This makes the mail from check meaningless as it's trivial to arrange for a 
random HELO name to pass SPF checks.  HELO pass overriding SPF Fail is only 
logical if the HELO name is known to you as a 'safe' host.  This is usable as 
a white listing technique, not a general purpose solution to dealing with the 
intersection of SPF and forwarding.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 17:35:46 +0200

> intersection of SPF and forwarding.

Pardon my being thick, but why would a helo name be easier to forge
than a bounce address?

Besides, we don't need to specify how different identities may concur
to form a "final" assertion, we can just specify the reject-on-fail
behavior such that it works in all cases, and can thus be recommended
to all hosts.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Apr 2012 12:04:26 -0400

On Friday, April 06, 2012 05:35:46 PM Alessandro Vesely wrote:
> > This makes the mail from check meaningless as it's trivial to arrange
> > for a random HELO name to pass SPF checks.  HELO pass overriding SPF
> > Fail is only logical if the HELO name is known to you as a 'safe' host.
> >  This is usable as a white listing technique, not a general purpose
> > solution to dealing with the intersection of SPF and forwarding.
> 

They are equally easy to forge.  

If the design is that a HELO pass overrides a Mail From fail then if HELO 
passes one can use arbitrary Mail Froms and SPF won't care.  Since there need 
be no relationship between HELO name and Mail From (and the specifically won't 
be in the case of forwarders) that means that all a sender needs to do is 
publish an SPF record for HELO and then the can use any Mail From they want.

That's why you can only use HELO pass to white list from SPF Mail From checks 
if you have reason to trust the host in question.  It doesn't work for 
arbitrary senders.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 18:53:07 +0200

On Fri 06/Apr/2012 18:18:50 +0200 Scott Kitterman wrote:
> publish an SPF record for HELO and then they can use any Mail From they want.

Yes!  IOW, if we can have forwarders publish an SPF record for (at
least) each mailout of theirs, it will then work reliably.

> if you have reason to trust the host in question.  It doesn't work for 

I fail to see how you derive the latter paragraph.  Nowadays, nobody
is sending out bounces after accepting a message.  Receivers who rely
on SPF results for bouncing can (and IMHO should) continue to use the
relevant SPF result for doing so.  Inducing backscatter seems to be
the only reason why a spammer would opt for gaming the Mail From
rather than Helo, but backscatter can be considered solved.

OTOH, we'd keep requiring the ability to publish an SPF record in
order to send from a given IP address.  And if we can sell
reject-on-fail as reliable and recommendable, it will get more adoption.
Casting the spam problem upon the market of throw-away domains was the
original SPF intent.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 06 Apr 2012 14:41:36 -0700

On 4/6/12 9:04 AM, Scott Kitterman wrote:
> >>>>>> The error correction that I'm proposing with issue #12
> >>>>>> substantially is that the helo identity must be checked
> >>>>>> by those who do reject-on- fail, and if it is a "pass"
> >>>>>> the receiver must not reject.
> >>>>
> >>>> This makes the mail from check meaningless as it's trivial to
> >>>> arrange for a random HELO name to pass SPF checks. HELO pass
> >>>> overriding SPF Fail is only logical if the HELO name is known
> >>>> to you as a 'safe' host. This is usable as a white listing
> >>>> technique, not a general purpose solution to dealing with the
> >> Pardon my being thick, but why would a helo name be easier to
> >> forge than a bounce address?
> >>
> >> Besides, we don't need to specify how different identities may
> >> concur to form a "final" assertion, we can just specify the
> >> reject-on-fail behavior such that it works in all cases, and can
> >> thus be recommended to all hosts.
 >
>  If the design is that a HELO pass overrides a Mail From fail then if
>  HELO passes one can use arbitrary Mail Froms and SPF won't care.
>  Since there need be no relationship between HELO name and Mail From
>  (and the specifically won't be in the case of forwarders) that means
>  that all a sender needs to do is publish an SPF record for HELO and
>  then the can use any Mail From they want.
>
>  That's why you can only use HELO pass to white list from SPF Mail
>  From checks if you have reason to trust the host in question. It
>  doesn't work for arbitrary senders.
Dear Scott,

Neither "Mail From" nor "Helo" offers protection from unknown senders, 
nor is either visible to recipients.  Reject messages on SPF "Helo" 
failures but not "Mail From".  Rejecting messages on "Mail From" failure 
is not compliant with unresolved forwarding conflicts.   Lack of 
compliance incurs support expenses not compensated by claims acceptance 
goes against a third-party desire to dictate handling that also lessens 
SMTP delivery integrity.   SPF should only require rejection for "Helo" 
check failures, not for "Mail From".

Regards,
Douglas Otis

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 07 Apr 2012 13:49:05 +0200

On Sat 07/Apr/2012 13:10:52 +0200 Douglas Otis wrote:
> failures but not "Mail From".  Rejecting messages on "Mail From"
> failure is not compliant with unresolved forwarding conflicts.   Lack
> of compliance incurs support expenses not compensated by claims
> acceptance goes against a third-party desire to dictate handling that
> also lessens SMTP delivery integrity.   SPF should only require
> rejection for "Helo" check failures, not for "Mail From".

Except for forwarding, however, the domain part of the mailfrom is a
better authentication token, because it is more meaningful and has an
SPF record more often, than the helo identity.

The SMTP's bar for the ehlo parameter is implausibly low, due to the
broadness of the context.  Raising the bar for the specific case of
forwarding may be more acceptable.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 Apr 2012 11:41:01 -0700

> forwarding may be more acceptable.
Dear Alessandro,

Consider http://tools.ietf.org/html/rfc6531 alters this concept of 
authentication "tokens" where exchange of U-labels rather than A-labels 
are not properly handled by SPF.  Only the EHLO response is limited to 
use of A-labels.   Per RFC5321, the same forwarding procedures first 
specified in RFC821 only defines forward path modifications where 
refusal of this accepted practice places a burden on providers where 
their customers may make upstream modifications in the delivery of their 
messages.   Domains using "-all" against the "Mail From" identity may 
conflict with explicit and valid desires of recipient without any 
reasonable solution available.  This issue does not exist when applied 
against the "Helo" identity.

Regards,
Douglas Otis

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Apr 2012 11:27:04 +0200

On Tue 10/Apr/2012 10:44:53 +0200 Douglas Otis wrote:
>>> SPF should only require rejection for "Helo" check failures,
>>> not for "Mail From".
>>
> authentication "tokens" where exchange of U-labels rather than
> A-labels are not properly handled by SPF.

IMHO, SPF should be compatible with EAI, I'll write a separate message
about this.

> Only the EHLO response is limited to use of A-labels.

In the "Domain / address-literal" part that may make an helo id, the
"Domain" can be an U-label when the server supports SMTPUTF8.

> Per RFC5321, the same forwarding procedures first specified in
> RFC821 only defines forward path modifications where refusal of
> this accepted practice places a burden on providers where their
> customers may make upstream modifications in the delivery of their
> messages.

> Domains using "-all" against the "Mail From" identity may conflict
> with explicit and valid desires of recipient without any reasonable
> solution available.  This issue does not exist when applied against
> the "Helo" identity.

Correct.  However, the publishing domain cannot specify which identity
-all is meant to be applied against.  At verifying time, two possibly
different result are obtained, and reflected in their own stanzas of
Received-SPF or Authentication-Results.  The accept-vs-reject decision
that we're talking about appears to be the only one place where the
two results are merged.

Your reasoning is also supported by Postel's principle.  The only
interpretation that supports reject-on-mailfrom-fail is the fact that,
due to its somewhat reduced significance, checking the helo identity
is not mandated.  This may seem a conceptual error similar to the
RR-type mismatch.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 05:38:10 -0400

> against the "Helo" identity.

It submit it does when the expectation is a 100% hop to hop chain of 
trust and the criteria is not always satisfied.

The basic problem as I view is the receiver making matters worst by 
disputing domain policies.  I suggest that you will have a lower 
benefit by not honoring domain policies by second guessing them, in 
fact, you may realize a greater attraction of attackers because of the 
continued weaker relaxed provisions the receiver offers to attackers.

The domain with -ALL main interest in protecting that MDA expected 
transaction.  What the MDA does beyond that initial protection is not 
defined by SPf should of recommending a lower strength policy for 
domains not aware of their domain usage and outbound activity.

I continue to believe that anything short of a hardfail is an 
extremely hight DNS waste on the network especially when you look at 
the high volume of NXDOMAIN that still exist.

In addition, the Hardfail policy offers a solution to mitigating the 
high abusive of legacy bad guys that don't hat to do anything but 
continue to spoof the domain.  Only a strong policy can protect 
against legacy abuse of spoofers.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 06:04:55 -0400

> is not mandated.  This may seem a conceptual error similar to the

Let me ask this question:

What is more important, protecting the remote domains or your own 
local domains?

To me, that is on-par with the Postel's principle, which fundamentally 
in general has always suggested you can only confidently protect your 
own domains first and what you know to be 100% true all the time, 
everything else come second.

Does it matter what EHLO/HELO, MAIL FROM is if RCPT TO fails?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Apr 2012 13:25:28 +0200

> What is more important, protecting the remote domains or your own

You don't trust an spf=pass due to smtp.helo, but you would have
trusted the same message if the sender had changed the smtp.mailfrom?

Given that malicious senders can change any part of the envelope, I
don't see why one of its parts would be trustworthier than another.

> everything else come second.

I meant http://en.wikipedia.org/wiki/Postel%27s_law

> Does it matter what EHLO/HELO, MAIL FROM is if RCPT TO fails?

No.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 08:03:41 -0400

> trusted the same message if the sender had changed the smtp.mailfrom?

In the anonymous world, a pass is meaningless, no trust.  It is with 
FAILURE where you get real deterministic value in the anonymous world. 
  Another way is to state that if a pass of one item MUST equal a pass 
for the other and it would be illogical to have a valid set of PASS 
and FAIL.  So if the premise is such a HELO must be valid, then a 
mechanism above and beyond SMTP could be useful using detected failure 
with a higher payoff than passage.  Same with MAIL FROM.

> don't see why one of its parts would be trustworthier than another.

Exactly.  So looking at one entity usually doesn't tell you the entire 
story.

>> Does it matter what EHLO/HELO, MAIL FROM is if RCPT TO fails?

I think so too.  Practically, it offers short-circuiting of DNS 
overhead.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Apr 2012 15:26:59 +0200

On Tue 10/Apr/2012 14:56:18 +0200 Hector Santos wrote:
> 
> In the anonymous world, a pass is meaningless, no trust.

I beg to differ.  A pass means that a domain claims some
responsibility on the SMTP transaction.  The receiver might be
temporarily unable to assess such domain's trustworthiness.  But we
believe reputation can be linked to domain names more consistently
than IP addresses.  That's what domain authentication is all about.

> It is with FAILURE where you get real deterministic value in the 
> anonymous world. Another way is to state that if a pass of one
> item MUST equal a pass for the other and it would be illogical to
> have a valid set of PASS and FAIL. So if the premise is such a HELO
> must be valid, then a mechanism above and beyond SMTP could be
> useful using detected failure with a higher payoff than passage.
> Same with MAIL FROM.

A pass cannot be spoofed, when using an authentication method worth
its salt.  If you get a pass on the helo identity, which actually
requires more setup effort than mailfrom, the difference is most
probably due to the nature of SPF being retrofitted to SMTP, rather
than integrated into it.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 09:53:41 -0400

> than IP addresses.  That's what domain authentication is all about.

Well, I am not sure if thats whats its all about.  Nevertheless, the 
only way for this to be theoretically and conceivably true is well, 
not to be anonymous and I guess you mean a 3rd party trust system 
where you would be known and not anonymous.  Again, key word - 
ANONYMOUS.  And this idea hasn't work and won't work because the 
"batteries required" market would not be universally persistent and 
consistent across all receivers.  If you can't reach consistent 
applicability of "Reputation" modeling then you have a security 
loophole of targeted receiver victims market where the "batteries" are 
not all the same or are lacking in various market segments.

---

From: Paul Midgen <[email-masked]>
Date: Tue, 10 Apr 2012 14:27:15 +0000

I'd submit that robust use of reputation is in practice not about domain or IP but both. We've been doing IP-based reputation for years very effectively using it to partition and group transmitting IPs based on threat level, how aggressive filtering should be, and so on. The real next-level application of it lies in some kind of entity-level correlation of IPs - things like registrar data (e.g. netblocks, ASNs, entity names), domains, and other orthogonal grouping methods that allow you to transitively use reputation.

To Alessandro's point, being able to segment (at a minimum) a domain's mailstream using the results of one or more authentication mechanisms is incredibly useful. We already know "pass" is most useful as a predicate for aggregating results.

I'm not entirely certain what the point of this discussion is though, since reputation is not part of SPFbis, and barring the presentation of incontrovertible data-based evidence there is no possible way this thread will cause major receivers to stop using path authorization and to discontinue deeply integrating it into IP and Domain reputation systems, positive identification feedback UX, and so on.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
Sent: Tuesday, April 10, 2012 6:27 AM
To: [email-masked]
Subject: [spfbis] Meaning of SPF and domain authentication in general, was #12

> In the anonymous world, a pass is meaningless, no trust.

I beg to differ.  A pass means that a domain claims some responsibility on the SMTP transaction.  The receiver might be temporarily unable to assess such domain's trustworthiness.  But we believe reputation can be linked to domain names more consistently than IP addresses.  That's what domain authentication is all about.

> anonymous world. Another way is to state that if a pass of one item 
> MUST equal a pass for the other and it would be illogical to have a 
> valid set of PASS and FAIL. So if the premise is such a HELO must be 
> valid, then a mechanism above and beyond SMTP could be useful using 
> detected failure with a higher payoff than passage.
> Same with MAIL FROM.

A pass cannot be spoofed, when using an authentication method worth its salt.  If you get a pass on the helo identity, which actually requires more setup effort than mailfrom, the difference is most probably due to the nature of SPF being retrofitted to SMTP, rather than integrated into it.
_______________________________________________
spfbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spfbis

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 11:32:51 -0400

Hi,

My only input is that in the world of *anonymous* transactions where 
most of the abuse exist, the only thing we have left from a common and 
universal applicability standpoint is protocol compliancy enforcement 
and only with the deviation from this expected compliancy can faults 
be leveraged.

The problem with EHLO/HELO SPF checking is that it can't be enforced 
and therefore legacy "bad guy" adaption can not be expected to occur. 
In other words, the easiest way for the bad guy to avoid it, is well, 
by simply not playing the game.  Don't use a valid EHLO/HELO domain, 
use the non-confirmable netbios or undotted string.  Don't use IP 
literal.  The only SMTP authorized solution to this is RFC4409 and 
even then MUAs don't always get it right and the MSA may have to delay 
its enforcement until the ESMTP AUTH required state is reached. 
Increasingly, MUA are behinds SOHO/Home tier with NAT environments 
where the connecting IP will not match the MSA/MUA exposed EHLO/HELO 
in any way.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 17:30:24 -0400

On Tuesday, April 10, 2012 11:27:04 AM Alessandro Vesely wrote:
...
> Your reasoning is also supported by Postel's principle.  
...
That was a principle for a different age.  While it is still useful in some 
cases it is not generally applicable.  It is certainly not applicable in 
trying to determine what mail to accept.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Apr 2012 14:32:54 -0700

On 4/10/12 8:32 AM, Hector Santos wrote:
>  most of the abuse exist, the only thing we have left from a common
>  and universal applicability standpoint is protocol compliancy
>  enforcement and only with the deviation from this expected compliancy
>  can faults be leveraged.
>
>  even then MUAs don't always get it right and the MSA may have to
>  delay its enforcement until the ESMTP AUTH required state is reached.

Dear Hector,

Thousands of new domains are registered daily.  See:
http://www.domaintools.com/internet-statistics/

It does not matter whether a domain is found in a "Mail From" or "Helo" 
SMTP parameter.  When nothing of the domain is known, the decision must 
be based upon default refusal, especially for domains normally not visible.

http://tools.ietf.org/html/rfc6531#section-3.7.1
,---
When an SMTP connection is opened, the SMTP server sends a "greeting" 
response consisting of the 220 reply-code and some information. The SMTP 
client then sends the EHLO command. Since the SMTP client cannot know 
whether the SMTP server supports SMTPUTF8 until after it receives the 
response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only 
ASCII (LDH label or A-label [RFC5890 
<http://tools.ietf.org/html/rfc5890>]) domains in the EHLO command. If 
the SMTPUTF8-aware SMTP server provides domain names in the EHLO 
response, they MUST be in the form of LDH labels or A-labels.
'---

Most email today is blocked by IP address reputation.  "Helo" permits 
use of domains to consolidate positive reputations.  In addition to 
RFC1918, which is easily solved by senders, LSN exchanges over 
100.64.0.0/10 represents a problem only be resolved by recipients.  
Inbound MTAs must offer IPv6 addresses or the 100.64.0.0/10 space can 
not be refused without being disruptive.  IP address authorization 
compliance requires exchanges uniquely identified by route-able IP 
addresses.  Consolidation of reputation for IPv6 is where "Helo" becomes 
both useful and practical.  For all the reasons previously stated, 
including UTF-8 encoded email addresses, Mail parameters can not be 
refused without disrupting valid email exchanges.

Combining multiple addresses within the From header field using 
http://tools.ietf.org/html/rfc6541 to authorize use (in conjunction with 
DKIM) offers a means to visually demonstrate affiliations.  This might 
be for something like From: [email-masked], 
[email-masked] where the known 
good-standing.reputation-service.domain authorizes the jon-doe.domain.  
This approach can only resolve UTF-8 addresses after having been 
converted to A-labels, but would be a perfect extension for DMARC as 
well as offering a means to adopt default refusal for unknown domains.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Apr 2012 21:42:50 +0000

> I beg to differ.  A pass means that a domain claims some responsibility
> on the SMTP transaction.  The receiver might be temporarily unable to
> assess such domain's trustworthiness.  But we believe reputation can be
> linked to domain names more consistently than IP addresses.  That's
> what domain authentication is all about.

+1.  "pass" is the only interesting case in DKIM, as well.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 18:21:30 -0400

On Tuesday, April 10, 2012 09:42:50 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Alessandro Vesely Sent: Tuesday, April 10, 2012 6:27 AM
> > To: [email-masked]

I agree that pass is the only interesting case for DKIM.  I agree that pass is 
interesting for SPF.  I very much disagree that it's the only interesting case 
for SPF.  My personal experience with having published a -all SPF record for 7 
or 8 years (I don't recall when I initially published it) is that it's been a 
mostly effective deterrent against spammers forging my domain (with the related 
almost total elimination of backscatter from such mails) with virtually no 
negative side effects.  

I find the fail case extremely interesting and unlike DKIM, where there's not 
integral policy mechanism, it's a core part of SPF to be able to take 
advantage of it.

Scott K

P.S.  I know there are false positives and not everyone is in a position to 
publish a -all record as a result.  I'm only speaking to my experience.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Apr 2012 15:35:18 -0700

> +1.  "pass" is the only interesting case in DKIM, as well.
Dear Murray,

Agreed.  However, when the "Mail From" identity references an SPF 
record, the result only offers an "authorization" not 
"authentication".   Higher levels of assurance would require SPF records 
to be specifically referenced by the "HELO".  Such specificity is simply 
not possible with SPF semantics.  This is also why SPF may not allow 
domains to defend their reputation.

Regards,
Douglas Otis

P.S. Lack of "Helo" specificity represents a basic departure from-
http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 18:57:53 -0400

> +1.  "pass" is the only interesting case in DKIM, as well.

It can easily be argued it was also its peril sans policy based 
protocol security wrappers.    DKIM is not SPF and the comparison is 
not there. The SPF framework is peppered with rejection guidelines 
when policy is violated out of the box.  This is not DKIM where 
failures are not promoted to unsigned signature statuses. This "DKIM" 
mindset MUST not creep into SPFBIS.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2012 19:02:52 -0400

Hector Santos wrote:
>>> From: Alessandro Vesely
> It can easily be argued it was also its peril sans policy based protocol 
> security wrappers.    DKIM is not SPF and the comparison is not there. 
> The SPF framework is peppered with rejection guidelines when policy is 
> violated out of the box.  This is not DKIM where failures are not 
> promoted to unsigned signature statuses.  This "DKIM" mindset MUST not
> creep into SPFBIS.

That should be:

   This is not DKIM where failures are promoted to unsigned signature 
statuses.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Apr 2012 23:03:59 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, April 10, 2012 3:22 PM
> To: [email-masked]
> Subject: Re: [spfbis] Meaning of SPF and domain authentication in general, was #12
> 
> I find the fail case extremely interesting and unlike DKIM, where
> there's not integral policy mechanism, it's a core part of SPF to be
> able to take advantage of it.
> 
> Scott K
> 
> P.S.  I know there are false positives and not everyone is in a
> position to publish a -all record as a result.  I'm only speaking to my
> experience.

Similarly, some places can do ADSP "discardable" and be totally happy with it.  It all depends on how a false negative will impact what you're doing.

But specifically in terms of developing reputation on a domain (which is what I was replying to), the "pass" case is the only interesting case for either mechanism.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 19:06:15 -0400

> http://tools.ietf.org/html/draft-ietf-marid-csv-csa-02

Your insistence on the distinction between authorized and authenticated making 
a difference is, in any practical terms, wrong.  We shouldn't get wrapped up in 
it here.  I think when RFC 5451 was published the issue was pretty well put to 
bed and trying to rehash it now is a waste of everyone's time.

BTW, it's a difference not a departure.  SPF HELO checking is unrelated to CSV.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 19:08:04 -0400

On Tuesday, April 10, 2012 11:03:59 PM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Tuesday, April 10, 2012 3:22 PM
> > To: [email-masked]
> Similarly, some places can do ADSP "discardable" and be totally happy with
> it.  It all depends on how a false negative will impact what you're doing.
> 
> But specifically in terms of developing reputation on a domain (which is
> what I was replying to), the "pass" case is the only interesting case for
> either mechanism.

As an input to a reputation system, I agree, but SPF has an independent 
utility in the absence of such a system.

ADSP is not part of the core DKIM protocol.  It's a after the fact bolt-on, so 
it's a bit different.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Apr 2012 23:15:27 +0000

> Sent: Tuesday, April 10, 2012 4:08 PM
> To: [email-masked]
> ADSP is not part of the core DKIM protocol.  It's a after the fact
> bolt-on, so it's a bit different.

Other than the fact that they're in separate documents, how are they different?

SPF receivers often elect not to bounce mail that fails SPF checks even with "-all" in the policy, specifically because of the false negatives concern.  Thus, they seem on par to me.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 19:19:32 -0400

On Tuesday, April 10, 2012 11:15:27 PM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Tuesday, April 10, 2012 4:08 PM
> > To: [email-masked]
> SPF receivers often elect not to bounce mail that fails SPF checks even with
> "-all" in the policy, specifically because of the false negatives concern. 
> Thus, they seem on par to me.

There are certainly similarities, but I think the false positive concern is a 
lot greater with ADSP.  It certainly is for me.  From my POV, ADSP is only 
suitable for a few high profile phishing targets while SPF -all is something 
that has general utility if one is willing to accept some noise level breakage 
in fringe cases.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Apr 2012 23:32:02 +0000

> Sent: Tuesday, April 10, 2012 4:20 PM
> To: [email-masked]
> There are certainly similarities, but I think the false positive
> concern is a lot greater with ADSP.  It certainly is for me.  From my
> POV, ADSP is only suitable for a few high profile phishing targets
> while SPF -all is something that has general utility if one is willing
> to accept some noise level breakage in fringe cases.

I'm still not seeing the difference.  If you publish "-all" then you're claiming you have very tight control over the path your email takes to get from you to wherever.  Doesn't that also mean DKIM failures are pretty much also under your control, or at least your influence?

(I think this is interesting, but we may be straying a bit afield for this WG list.  Feel free to drag this to ietf-dkim or spf-discuss if the chairs slap our wrists.)

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 19:47:51 -0400

On Tuesday, April 10, 2012 11:32:02 PM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Tuesday, April 10, 2012 4:20 PM
> > To: [email-masked]
> I'm still not seeing the difference.  If you publish "-all" then you're
> claiming you have very tight control over the path your email takes to get
> from you to wherever.  Doesn't that also mean DKIM failures are pretty much
> also under your control, or at least your influence?
> 
> (I think this is interesting, but we may be straying a bit afield for this
> WG list.  Feel free to drag this to ietf-dkim or spf-discuss if the chairs
> slap our wrists.)

Since our wrists are thus far unslapped ...

The difference is the failure cases.  For SPF it's a combination of forwarding 
and poorly considered SPF checking (when can argue in what proportion in the 
other thread) and some web based applications that spoof Mail From.  Because 
of the effect of years of education there are relatively fewer web applications 
doing this kind of thing than there used to be.  Here's a page of advice 
that's been around since at least 2004 if not before:

http://www.openspf.org/Best_Practices/Webgenerated

Comparing this to DKIM, there are similarities and differences.  DKIM 
signatures should survive forwarding, so forwarding is not an issue for 
DKIM/ADSP, but mailing lists are and so are all the web apps that use the 
user's email address in the 5322.From (and many that use their own 5321.Mail 
>From use the user's 5322.From).  As a result, a lot of normal use of email 
addresses ends up being unsigned (in the examples in the openspf.org link, one 
would be OK from a DKIM/ADSP point of view and one would be problematic).

It's my contention that the cases that most users care about are much more 
likely to be a problem for DKIM/ADSP than SPF.  That's consistent with data 
I've seen, but I can't give you hard numbers.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Apr 2012 17:31:09 -0700

On 4/10/12 4:06 PM, Scott Kitterman wrote:
> > "authentication". Higher levels of assurance would require SPF
> > records to be specifically referenced by the "HELO". Such
> > specificity is simply not possible with SPF semantics. This is
> > also why SPF may not allow domains to defend their reputation.
> >
> > Regards, Douglas Otis
> >
>  Your insistence on the distinction between authorized and
>  authenticated making a difference is, in any practical terms, wrong.
>  We shouldn't get wrapped up in it here. I think when RFC 5451 was
>  published the issue was pretty well put to bed and trying to rehash
>  it now is a waste of everyone's time.

Dear Scott,

This argument can be avoided by simply using correct and accurate 
terminology.
http://tools.ietf.org/html/rfc5451#section-1.5.2

Clarifies SPF offers authorization and not authentication, as does the 
title for RFC4408.  Why misuse clearly defined terminology?  Why 
misrepresent two different functions providing significantly different 
outcomes?

A difference that permits the following assertion "This may have been 
sent by your bank" when a source was authorized versus "This has been 
sent by your bank" when a source is authenticated.  I think most see the 
practical difference in these two statements.  There is a fairly high 
number of servers being compromised.  Statements that SPF authenticates 
a source grossly overstates assurances SPF can offer.

>  it's a difference not a departure. SPF HELO checking is unrelated
>  to CSV.

CSV is specifically referenced by "Helo" and precludes "Mail From" 
authorizations.  The difference is authentication versus authorization. :^(

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Apr 2012 21:43 -0400

> authorizations.  The difference is authentication versus authorization. :^(

In real life these don't make any difference at all.

If I can compromise a server that's configured to DKIM sign for a domain, then 
I can send arbitrary mail signed by that domain.  If the same server is also 
listed in the domain's SPF record, they will also pass SPF.  In real life both 
DKIM pass and SPF pass mean "passed through a server the domain had some 
positive opinion of".

We'll say in SPFbis that SPF does authorization, don't worry, so we don't need 
to waste more of the working group's time on this, but it's of no consequence 
either way.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Apr 2012 04:53:45 -0400

> misrepresent two different functions providing significantly different 

Hi Doug,

Hmmm, I don't wish to get into AA (Authentication and/or 
Authorization) semantic debates, but I agree with Scott.   I view 
authentication defining who the client is and authorization defining 
what the client is allowed to do. There are legacy protocols that are 
based on this AA duality and we don't need to go much further than 
RADIUS which has its in its protocol title the term "Authentication"

         Remote Authentication Dial-In User Service (RADIUS)

which is just login phase of the protocol. Phase two is the collection 
the dictionary tokens to established the line and/or user 
authorization levels and phase three is packet signaling to initiate 
and also end the accounting recording and protocol session.  All 
protocols that inherently include a LOGIN concept offers the similar 
AA duality framework.

> practical difference in these two statements.  

I don't and IMV, the latter is not a good example for authentication. 
  I would suggest:

    "I am the BANK"

is an example of authentication.  Perhaps because it may not be a good 
example using banks with its high-value user/vendor communications 
needs because your example illustrates the promotion of  the social 
engineering "Cry Wolf" syndrome - "This may have been sent by your 
bank" is not ideal for an authorization concept. Perhaps better "This 
bank service MAY not be available to you" works better.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Apr 2012 10:18:08 -0700

On 4/10/12 6:43 PM, Scott Kitterman wrote:
>> Dear Scott, This argument can be avoided by simply using correct and 
>> accurate terminology. 
>> http://tools.ietf.org/html/rfc5451#section-1.5.2 Clarifies SPF offers 
>> authorization and not authentication, as does the title for RFC4408. 
>> Why misuse clearly defined terminology? Why misrepresent two 
>> different functions providing significantly different outcomes? A 
>> difference that permits the following assertion "This may have been 
>> sent by your bank" when a source is authenticated. I think most see 
>> the practical difference in these two statements. There is a fairly 
>> high number of servers being compromised. Statements that SPF 
>> authenticates a source grossly overstates assurances SPF can offer.
Dear Scott,

Thank you for that assurance, but I still strongly disagree with your 
assessment of significance simply because it has become increasingly 
routine to find compromised servers. :^(

The growing rate of compromised systems leads to a significant 
difference between authentication and authorization in the overall 
numbers of individuals and domains affected.  This becomes significant 
in how SPF is to be used and whether it should supplant authentication 
schemes.

Muddled use of these two terms often justifies misleading hyperbole 
about assurances offered.   It is possible to implement prefix semantics 
like "_helo." to constrain which SMTP parameters reference records for 
example, but this would require recognition of a losing battle.  
Clarifying these terms better highlights value found in the SPF results 
headers (in a write-up that is still owed).

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Apr 2012 18:00:37 -0400

> routine to find compromised servers. :^(

Are you describing a technical problem or a policy problem?

> headers (in a write-up that is still owed).

Doug,

One of the key problems has always been that the EHLO/HELO validity 
can not be enforced for long time legacy reasons and even with updated 
MTAs, its not always reliable to provide a valid and correct public 
domain name or IP literal.

However, when there is clear intent to "FAKE" a spoof, this is a 
zero-false positive detectable rejection case.  Part of the robust 
principle is that a RECEIVER knows how it can handle its own local 
information and knows less how to handle remote information. For 
example, these are examples of client intent to fake information:

      Invalid HELO [208.247.131.9] - client address [58.216.241.6]
      Invalid HELO mail.winserver.com - client address [118.114.245.48]

The first is our IP and its an easy non-SPF IP literal syntax check, 
and the 2nd is SPF protected.  So the first highest benefit is 
achieved by protecting your own property.  However, the efficacy goes 
does down when its remote information. This is where the high DNS 
waste begins with helo SPF checking.

But another key issue is understanding when the basic LMAP methodology 
and applicability for IP::HELO or the IP::MAILFROM authentication 
assertions.

   Note, I can't the ietf.org archive of the LMAP draft I-D, but I
   still have a copy here:

http://isdg.net/Public/ietf/drafts/draft-irtf-asrg-lmap-discussion-00.txt 

I think this could be good review/reading to understand some of the 
SPF insights. See the summary which begins a clear fundamental 
understanding of what all the LMAP protocols were designed to offer.

    1.1 Summary of the Protocol

    LMAP is based on two concepts: publication of policy by a domain, and
    application of that policy by a recipient MTA.  The combination of
    these concepts permits SMTP originators and recipients to reach more
    informed consent when exchanging messages.

    The policy published by a domain includes statements as to which IP's
    are permitted to claim association with the domain in SMTP EHLO/HELO
    and MAIL FROM.  That policy can request certain decisions to be made
    by a recipient on behalf of the domain.  For example, "mail from
    example.com originates solely from the machine mail.example.com.
    Please reject mail allegedly from example.com which originates
    elsewhere."

For implementations of LMAP protocols, it became prudent to understand 
the critical importance for optimized deployment in order to justify 
the  blind application of these new DNS-based concepts knowing there 
is was going to be a very high NXDOMAIN yield of queries, especially 
during the short term. This is why I did the LMAP analysis:

    http://isdg.net/public/antispam/lmap/draft-smtp-lmap-santos-02.htm

My main point in all this is that we should keep a perspective of how 
and when SPF is applied within the end to end transport path. helo 
checking ideas is not always applicable in the same way Mail From 
checking is not always applicable.  Ideally, we should perhaps 
consider SPFBIS having semantic describing the basic applicability 
framework of:

   o 5321.MAILFROM checking recommended for MUA to MDA paths.
     - 5321.HELO checking expected to have a failure factor with MUAs

   o 5321.HELO checking recommended for MTA to MTA paths.
     - 531.MAILFROM checking expected to have a failure factor after 
initial HOP

The problem is that in the anonymous world, the SMTP receiver will not 
know if the client is a MUA or MTA, when 5321.HELO or 5321.MAILFROM 
checking should be done and in what order and how much confidence 
weight should be considered to each or when one should override the other.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Apr 2012 11:37:53 +0200

On Fri 13/Apr/2012 11:04:51 +0200 Hector Santos wrote:
> 
> Ideally, we should perhaps consider SPFBIS having semantic
> describing the basic applicability framework of:
> 

RFC 4408 seems to assume that there's no use in checking SPF on a
submission server or during an authenticated SMTP session.  This might
be better clarified in SPFBIS.

> know if the client is a MUA or MTA

SUBMIT servers do know.  Curiously, RFC 4405 claims to be appropriate
for the submission protocol too.  The examples it gives of mobile and
guest users look rather archaic to me.  Are there still people who
pick submission servers casually?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Apr 2012 10:24:17 -0400

> be better clarified in SPFBIS.

What needs to be clarified?  That checking to see if a non-MTA is an authorized 
MTA is not a good idea?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Apr 2012 17:59:12 +0200

> What needs to be clarified?  That checking to see if a non-MTA is an authorized 

That SPF is not designed to recognize affiliated MUAs.  If it were an
SMTP extension I'd expect it not to be appropriate for the submission
protocol.  I'm surprised this is not the case for RFC 4405.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Apr 2012 12:05:09 -0400

On Friday, April 13, 2012 05:59:12 PM Alessandro Vesely wrote:
> > What needs to be clarified?  That checking to see if a non-MTA is an
> > authorized MTA is not a good idea?
> 

I don't think it's reasonable in an RFC to enumerate all the things a protocol 
does not do.

RFC 4405 is just PRA selection.  Anytime you have a message body you can do 
that selection.  What you can't do is apply it to Sender ID from an MUA (just 
as you can't SPF).

The one submission related practice that I have seen is a prospective check to 
determine if the message were to be sent from the submission server would it 
pass SPF.  I think that can be useful, but I don't think it needs to be 
standardized.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Apr 2012 19:34:05 +0200

On Fri 13/Apr/2012 19:18:23 +0200 Scott Kitterman wrote:
>> SPF is not designed to recognize affiliated MUAs.  If it were an 
>> SMTP extension I'd expect it not to be appropriate for the
>> submission protocol.  I'm surprised this is not the case for RFC
>> 4405.
> 
> I don't think it's reasonable in an RFC to enumerate all the things
> a protocol does not do.

SUBMIT mentions IP address restrictions as a way to authorize
submission.  That's usually done by configuring (internal) valid IP
addresses directly, rather than taking recourse to an "internal" SPF
record.

> RFC 4405 is just PRA selection.

I meant the SMTP extension.

> pass SPF.  I think that can be useful, but I don't think it needs to be 

Just to make that clear, you mean a submission server could apply SPF
checks against its mailout's IP address in order to verify the
Return-Path that the user configured?  Such kind of action is
described in http://tools.ietf.org/html/rfc6409#section-6.1 but
without explicitly mentioning SPF as a tool.

---

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

> be better clarified in SPFBIS.

+1.

We can probably add to the above:

    o SPF is not required when the user or client is authenticated using
      current IETF standards and practices for SMTP.

It has been a long time practice ISP/SMTP public port receiver to follow:

    - authentication is not required for local mail or locally
      hosted domain mail acceptance.

    - authentication is required for relaying mail.

I alway had the mindset that all this extra JUNK was a waste, but it 
did begin to offer a problem resolving solution to address the high 
abuse of non-authenticated local mail reception we could no longer 
ignore and pass off to the sysop.

But if the user was authenticated using the traditional methods, all 
the extra new stuff was really just big overhead with low payoff waste 
of time.  The exception was the possible applicability to deal with 
the "Compromised Users" problem but IMV, that was  a different problem 
with a different set of solutions which may include pattern 
recognition and excessive transaction monitoring.

IP authentication was the first method ISP used with user's dialup PPP 
connections and eventually full time connectivity. It is still used as 
the only authentication necessary to relay mail and for the most part, 
with no restrictions on the addresses you use or even what 
RFC822/2822/5322 contained. Its was really none of our business! :)

The real problem was the advent of the Roaming User which came in many 
forms and now the low cost, low overhead, automated User PC 
connectivity to the ISP network with IP authentication method was not 
reliable.  The user was still allowed to send mail to local users 
anonymously, but you could not relay.

With the "invention" of original Extended SMTP (RFC1993) and its 
extended service extensions with ESMTP AUTH (RFC2554) and SUBMIT 
(RFC2476), it began to offer a solution to the Roaming User problem, 
but there was still a dearth of supported MUAs.  It was not a 
guarantee the user had a updated MUA and it was often a major support 
cost to document and train users to switch and/or configure MUA for 
ESMTP AUTH.  If the user had an MUA that was not part of the top brand 
illustrations, he was SOOL!

In fact, I recall long ago with my home ISP account, the ISP sending 
an email mandating a pending July cutoff date to force users switch to 
ESMTP AUTH ready MUAs.  I recall their reasons were stupid - to 
address the spam problem.  So it was predictable they would have a 
support problem.  Within a month,  a follow up email basically said 
"Never mind!"  The ISP was experiencing a huge major help desk support 
cost problem when the practical reality was it wasn't necessary for 
most users who were IP authenticated via their connection and ESMTP 
AUTH was still new.  Not every MUA supported it.  There were other 
solutions available for the Roaming User issue too, like POP3 B4 SMTP 
which drastically help reduce the training cost associated with 
helping users setup ESMTP AUTH.

> SUBMIT servers do know.  

Why do you think that? Do you mean the idea of enforcement allowed by 
4409 suggest the EHLO will be or MUST be valid and known?

The modern problem is that the MUA still may not present a proper 
public domain name and with the advent of NATs, the fallback to using 
the domain IP literal could be incorrect.  Users behind the NAT may 
present the private IP literal in their EHLO/HELO field which doesn't 
match the NAT connecting public IP address.  So this is an example 
where EHLO/HELO can not be enforced via 4409.

> Curiously, RFC 4405 claims to be appropriate for the submission 
> protocol too. The examples it gives of mobile and guest users look 
> rather archaic to me.  

I consider it overhead and waste of time to worry about all these SMTP 
augmented technology when user authentication is active or expected 
via 4409.

> Are there still people who pick submission servers casually?

Well, isn't prearrangement a basic presumption with a protocol or any 
client/server negotiation expecting authentication?

Perhaps the question is do people pick ESP host casually? Either as 
one's default email account, an additional secondary account, like 
with gmail.com?  Isn't all prearranged in some form?

What would be interesting is how gmail.com allows for secondary 
accounts with for:

    1) allowing gmail MTAs to send mail, or
    2) allowing your own host to send the mail.

I was interested in testing this for both SPF and DKIM so I had 
prepared a secondary account [email-masked] to see what 
needed to be done.

When you choose #1, gmail.com is the primary source where the mail is 
created so it just sends mail out to the MDA (non-authenticated). 
But if you choose #2, it will ask for:

    SMTP Server: mail.winserver.com
    User Name: xxxxxxxxxxx
    Password: xxxxxxxxxxxxxxxxx

In the first case, ESMTP AUTH is not active and gmail will use its MTA 
to MDA:

     IP            <-- 209.85.212.178
     5321.EHLO     <-- public domain, mail-wi0-f178.google.com
     5321.MAILFROM <-- your primary address, [email-masked]
     5322.SENDER   <-- your primary address, [email-masked]
     5322.FROM     <-- your secondary account, 
[email-masked]

The only protection I have against any potential spoofing of my 
winserver.com property is to use ADSP/ATPS where I authorize the 3rd 
party gmail.com DKIM signing of my 5322.From Author Domain 
winserver.com.  No ADSP/ATPS support.  No protection.

In the 2nd case, where ESMTP AUTH on port 587 is active with its MTA 
to MSA:

     IP            <-- 209.85.212.178
     5321.EHLO     <-- public domain, mail-wi0-f178.google.com
     5321.AUTH     <-- local user account/pwd
     5321.MAILFROM <-- secondary address,  [email-masked]
     5322.SENDER   <-- NONE
     5322.FROM     <-- secondary account, [email-masked]

With ESMTP AUTH authentication, SPF is skipped.  But if SPF was to be 
applied, well, first gmail.com has no SPF record for the EHLO domain 
and for 5321.MAILFROM I would have to have a local white list filter 
rule like:

    ACCEPT IF %CIP% is "209.85.212.178" and %RDP% is "winserver.com"

Of course, my MSA would not know what IPs are used by gmail, but since 
the session was authenticated, all this junk is now unnecessary.  It 
should be noted GMAIL did not sign the MTA to MSA submitted message 
which I believe is proper to allow the MSA to do necessary signing if 
the message was going to be relayed.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 13 Apr 2012 19:59:18 +0200

> protocol.  I'm surprised this is not the case for RFC 4405.

I have to agree with Scott here. There are many many other situations 
where SPF is not designed for. I have several customers using hosted 
AS/AV services like Postini and MessageLabs and it makes no sense 
whatsoever performing SPF checks on any intermediate internal 
MSA's/MTA's between an internal mail client and the exterior AV/AS 
service. We're not going to document that either.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 17:55:14 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Friday, April 13, 2012 10:59 AM
> To: Alessandro Vesely
> Cc: [email-masked]
> >>> submission server or during an authenticated SMTP session.  This
> >>> might be better clarified in SPFBIS.
> >>

+1, and also +1 to the point that we don't want to start down the path of documenting everything SPF isn't.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 15:34:12 -0400

> service. We're not going to document that either.

I believe it should be documented to HELP minimize unnecessary 
overhead on the network where it is not required.

SPF is one of those heavy DNS-based protocols where its PRUDENT to be 
aware of network optimization insights simply because it has a low 
payoff with a high NXDOMAIN yield in blind application.

Is it really so obvious that it doesn't need to be stated?  It might 
be obvious to the active WG participants and next editors of the spec, 
but I suggest it may not be obvious to the general future reader and 
implementor.

Besides the specs is already filled with what we believe to be 
obvious, such as Parallel Queries concepts with the obvious and 
natural expectation, that your favorite API already supports it and 
therefore its obvious that all others do as well.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Apr 2012 15:47:57 -0400

No hat.

On Fri, Apr 13, 2012 at 03:34:12PM -0400, Hector Santos wrote:

> Is it really so obvious that it doesn't need to be stated? 

If we used this standard for everything about the DNS that isn't so
obvious, every RFC that uses the DNS would be 500 pages long.  

Those who are arguing for inclusion: What is the reason this _does_ need
to be stated?  As various people are rumoured to have said[1],
"Perfection is achieved not when there is nothing left to add, but
when there is nothing left to take away."

Best,

A

[1]I believe the rumour about Saint-Exupery, myself.

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 15:55:19 -0400

Scott Kitterman wrote:

>> Alessandro stated:

Why not?  After all, if its not written, you (speaking in general) 
will mostly likely remind people when the do begin to do things the 
protocol did not expect in unwritten terms.   Thats half the problem 
now. no?

> that selection.  What you can't do is apply it to Sender ID from an MUA (just 

Not following. Can you elaborate it?

My view, 4405 is not complex.  Its just the exposure of the PRA at the 
SMTP level to help preempt the payload download.  I think what is 
forgotten when all this was being put together the idea of a SMTP 
receiver doing DATA level shimming and call outs was still in its 
infancy.  The larger scale you were, the less odds you were today 
dynamic DATA level processing.  So it was important to optimize the 
SPF/SIDF protocol with the SUBMITTER extended SMTP option.  It was 
documented and patented as an necessary OPTIMIZATION to help avoid 
payload overheads when in FACT over 80% of the transactions the PRA 
was the same as the 5321.MAILFROM and it was NOT desirable to find out 
that wasted fact by accepting the message first. Get it?

> pass SPF.  I think that can be useful, but I don't think it needs to be 

+1, but I don't view it as a standardization, but rather providing 
engineering design insights.  Perhaps as an possible answer to the 
"Compromised User" question.

Can it help this particular real potential problem?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 19:56:46 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, April 13, 2012 12:48 PM
> To: [email-masked]

The one about public suffix being his idea?

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 16:12:31 -0400

Sure, I can see your point Andrew, but IME, I believe rhetorical 
philosophy as a general application isn't always applicable across the 
board.  As you are well tuned to the fact, it may apply as a general 
principle but there are cases where the motto "Being Specific is 
Terrific" does offers a faster grasp in understanding.

Background: I view the RFC as a blend of two phases of the software 
engineering process with a functional and technical specification 
reaching a wider audience of multiple disciplines. Hence therefore, I 
suggest catering to the non-technical layman (i.e. management, tech 
sales, suppport) per se, in areas that less understood and only more 
obviously understood by the singular audience of technical people is 
all important. I personally find RFC having too much investment in 
presumed understanding of all its writes about.

PS: I spent 10 years in the corporate (Westinghouse Electric) and 
federal documentation world making sure engineers, management and 
politicians understood what was presented.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Apr 2012 16:37:01 -0400

> I meant the SMTP extension.

It does say it's not relevant to submission.  I don't agree it's necessary to 
say that for SPF.

> > The one submission related practice that I have seen is a prospective
> > check to determine if the message were to be sent from the submission
> > server would it pass SPF.  I think that can be useful, but I don't think
> > it needs to be standardized.
> 

Yes.  that's what I mean.  I'd say 6409 6.1 is describing what should be done.  
What I mention is is one method for how to go about it.  It has no 
interoperability or protocol implicaitons, so I don't think it needs 
standardization.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Apr 2012 16:51:29 -0400

On Friday, April 13, 2012 03:55:19 PM Hector Santos wrote:
> > I don't think it's reasonable in an RFC to enumerate all the things a
> > protocol does not do.
> 
> > that selection.  What you can't do is apply it to Sender ID from an MUA
> > (just as you can't SPF).
> 

I had 4405 and 4407 reversed in my head when I wrote that.

> that wasted fact by accepting the message first. Get it?

There is no such thing as the SPF/SIDF protocol.  They are separate things.  
The only technical relationship they have is the unfortunate design decision 
by Microsoft to re-purpose SPF records for SIDF.

> Can it help this particular real potential problem?

It can, but I don't think it's related to the work of this group.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Apr 2012 21:35:29 +0000

> Sent: Friday, April 13, 2012 1:51 PM
> To: [email-masked]
> > > The one submission related practice that I have seen is a 
> > > prospective check to determine if the message were to be sent from 
> > > the submission server would it pass SPF.  I think that can be 
> > > useful, but I don't think it needs to be standardized.
> >

Once again, I think a deployment document might ultimately help.  This is where stuff that isn't part of the protocol definition itself would go.

If there's some small amount of pedagogy, that can probably go in an appendix of RFC4408bis.  If the working group actually has quite a lot to say, on more than one or two topics, we should consider a separate document.

I know that's not in our current charter, but I'd like to do some investigation into whether or not we could/should do this after 4408bis is done, as part of a re-charter.  So if the chairs don't mind: Please reply to this (new) thread if you have any topics you'd like to see us discuss somewhere that would qualify not as protocol specification, but as implementation and/or deployment advice.  Based on the volume and content, we can decide whether or not this is something we should do, and where.

Either way, this is not work we should actually plan on starting until after RFC4408bis is basically done.  But I think asking this question now and collecting ideas will help decide (a) what goes into RFC4408bis, and (b) whether or not we should seek to add this as a deliverable when/if we re-charter.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 19:11:30 -0400

> There is no such thing as the SPF/SIDF protocol.  They are separate things.  

Well Scott, I understand the sentiment but it was the genesis, purpose 
and reason why there was a 2006 IETF conclusion to explore the 
integrated co-existence of the multiple protocols.

> by Microsoft to re-purpose SPF records for SIDF.

Ok good, thats a start. There is conflict with it.  Spell it out. 
Honestly, I would like to know why 4407 was a bad idea.

> It can, but I don't think it's related to the work of this group.

I think it is perhaps from the standpoint to point out that it MAY NOT 
solve the Compromised User Problem.  Or could it?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Apr 2012 16:49:04 -0700

Dear Hector,

This concerns MSAs where your network, your rules apply.  IMHO, the role 
most have for SPF is for unauthenticated (port 25) traffic between 
different ADMDs.  The RFC5321 <reverse-path> is not bound to a specific 
ADMD which is where SPF framework fails.  SPF does not permit valid 
operations of http://tools.ietf.org/html/rfc5321#section-6.1 and 
http://tools.ietf.org/html/rfc1123#section-5.2.6 which is why many 
ignore "-all" and this represents a serious conflict that must be resolved.

It is reasonable to reject failures based upon HELO/EHLO identities as 
this avoids the issues with RFC1123 and RFC5321.  ADMDs unable to 
properly configure their greeting or define their sources with a 
protocol that permits more than 100 DNS transactions is absurd when 
checking EHLO/HELO identities.  However, it is not reasonable to expect 
even this number of DNS transactions will be able to accommodate the 
entirety of all possible reverse-paths as email is currently defined.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 22:12:50 -0400

> There is no such thing as the SPF/SIDF protocol.  They are separate things.  

Scott, to the integrator it was a clear TOTAL SOLUTION SPF framework.

The 2006 IETF experiment of the integrated coexistence of these 
multiple protocols was the principle reason for its exploration. 
While I am clearly sympathetic to the SPF1.0 only crowd and its cited 
conflicts with SPF2.0, the reality was such is that a proposed PAYLOAD 
based 3rd identity domain called the PRA was considered to be part of 
the use cases and one the SMTP only SPF1.0 protocol did not cover. 
All together, I hate to repeat it:

   - 5321.EHLO/HELO
   - 5321.MAILFROM
   - 5322.PRA

I think we forget why SPF had a allure to it as a ACCEPT/BOUNCE 
mitigating solution.  The 5322.PRA defeated that purpose and during 
this time frame, lets note large scale systems were not global BCP 
position to apply it at the DATA level. The mail had to be accepted. 
Again, that payload acceptance concern led to the RFC4405 SMTP level 
exposure of the PRA keeping it all at 5321:

   - 5321.EHLO/HELO
   - 5321.MAILFROM
   - 5321.SUBMITTER

> by Microsoft to re-purpose SPF records for SIDF.

While I never did quite get the "AH HA" behind the PRA value, I 
recognized it was an option that needed to be supported in the 
integrated protocol. But overall, I had always failed to see your and 
similar cited concerns because to the Integrator the two TXT records 
were clearly separated.

I never disputed there was a concern. I just didn't quite see it, and 
I would think the effort to look at the experiment results could FOCUS 
on the value of the PRA and/or  resolving the so called SPF1.0/2.0 
policy conflicts that is stated to exist.

What exactly is the conflict?  Can it be resolved? Or is still a dead 
horse?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Apr 2012 22:31:43 -0400

> exposure of the PRA keeping it all at 5321:

Such a total protocol solution doesn't exist.  It was the goal of MARID to 
produce such a protocol, but it was concluded for non-technical reasons and 
revisiting all this history is specifically off topic for the working group.

Personally, I don't see any value in 5321.SUBMITTER.  Unless the bad guys are 
being idiots, it won't save you from going to DATA anyway.

> > The only technical relationship they have is the unfortunate design
> > decision by Microsoft to re-purpose SPF records for SIDF.
> 

It's dead IMO.  Even if it weren't dead, the non-technical barriers to 
completing MARID still exist so there's no point in spending a lot of time on 
figuring out the technical points.

All off topic and we should probably stop.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 22:37:54 -0400

Douglas Otis wrote:

> different ADMDs.  

Wasn't this already stated?

> The RFC5321 <reverse-path> is not bound to a specific 

Many? like who? anyone who is ignoring the -ALL policy is violating 
RFC4408 and worst, assuming product liability that was possibly 
repudiated by the domain policy.

I would be one to advise the chief council of such operations where 
this intentional neglect to follow standard practice risk malpractice 
product liability claims.  It would best to just not do any SPF, drop 
support, rather than pretend and make up your own rules that negates 
and conflicts with the standard explicit domain policies.

If a domain says THIS IS BAD and you say I DON"T BELIEVE YOU, then you 
take on all product and consumer liability - automatically.

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Apr 2012 23:00:34 -0400

Scott Kitterman wrote:

> Such a total protocol solution doesn't exist.

How can state this when any SMTP-SPF server that supports SUBMITTER 
and all the clients that also leverage it clearly exist?

Just because you never support it, doesn't mean the integrated 2006 
IETF consideration was a fallacy.

> It was the goal of MARID to produce such a protocol, but it was concluded 
> for non-technical reasons and revisiting all this history is specifically 
> off topic for the working group.

Huh?  You admit that it was a goal but blab without any evidence that 
it was concluded to be unintentional and to try to kill it as off topic?

> Personally, I don't see any value in 5321.SUBMITTER. 

Ok, tell us why?

> Unless the bad guys are being idiots, it won't save you from going 
> to DATA anyway.

Thats like saying the BAD GUY can also be SPF 1.0 compliant too! I 
think since you never implemented 4405, you lack insight into it 
possible value or usage.

In essence what you were suggesting there was no valid PRA use case. 
Thats not a technical  opinion, but a policy mandate.  Should I 
believe you or claims by others that the PRA works great with 
RESENT-FROM headers?

> figuring out the technical points.

Moving hand over head.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 Apr 2012 16:40:54 +0200

On Sat 14/Apr/2012 15:21:33 +0200 Scott Kitterman wrote:
> It does say it's not relevant to submission.

It says it is "appropriate", see point (6) of
http://tools.ietf.org/html/rfc4405#section-2

Irrespectively of the possible merits of RFC 4405, that point might
generate confusion, since the protocols are somewhat similar.  That's
why I proposed to state the opposite.

>  I don't agree it's necessary to say that for SPF.

No, it's not necessary.  However, if we add a paragraph about
submission and the verification quoted below, then it would take just
one extra sentence.

>>> prospective check to determine if the message were to be sent
>>> from the submission server would it pass SPF.  I think that can
>>> be useful, but I don't think it needs to be standardized.
>> 
>> Just to make that clear, you mean a submission server could apply
>> SPF checks against its mailout's IP address in order to verify
>> the Return-Path that the user configured?  Such kind of action
>> is described in http://tools.ietf.org/html/rfc6409#section-6.1
>> but without explicitly mentioning SPF as a tool.
> 
> Yes.  that's what I mean.  I'd say 6409 6.1 is describing what
> should be done. What I mention is one method for how to go about
> it.  It has no interoperability or protocol implications, so I
> don't think it needs standardization.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 Apr 2012 16:45:24 +0200

On Sat 14/Apr/2012 16:12:56 +0200 Hector Santos wrote:
> Douglas Otis wrote:
> 
>> The RFC5321 <reverse-path> is not bound to a specific ADMD which is
>> where SPF framework fails.  SPF does not permit valid operations of
>> http://tools.ietf.org/html/rfc5321#section-6.1 and
> Many? like who?

Gmail, for one.  They register the failure, don't check the helo
identity, and deliver the message regularly.  That's fine, IMHO.

> anyone who is ignoring the -ALL policy is violating RFC4408 and
> worst, assuming product liability that was possibly repudiated by
> the domain policy.

SPF cannot guarantee that publishing -ALL ensures rejection.  There
will always be SPF-ignorant servers, and servers like gmail that check
but don't reject.

Actually, it seems to me that those who reject can be accused of
breaking those SMTP features.  To resolve the conflict we must devise
a safe way of rejecting, such that servers can adhere to it with no
risks.  Our task is not to mandate it, but to enable it.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Apr 2012 10:51:38 -0400

> why I proposed to state the opposite.

Never mind that.  I had 4405 and 4407 switched when I wrote that.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Apr 2012 10:59:13 -0400

> IETF consideration was a fallacy.

What was considered in 2006 was not an integrated protocol.  It was two 
independent submissions, one of which used aspects of the other.

> it was concluded to be unintentional and to try to kill it as off topic?

It was a goal, but it failed.  Specifics of why are specifically off topic, but 
it is indisputable that no RFCs came out of the MARID working group.

> > Personally, I don't see any value in 5321.SUBMITTER.

At the envelop layer SUBMITTER is a made up ID that carries a promise that 
later, if you go to DATA, you'll discover has some relevance to a header in 
the body.  It could be anything.  I don't see any value in knowing before DATA 
that resent-sender is some particular domain.

> believe you or claims by others that the PRA works great with

It depends on what you mean by great.  PRA is useful if you are worried about 
resent-sender forgery.  I am not.  Other than that, it just gives you a domain 
to use as an input to a reputation system and as such is a "batteries needed" 
protocol and not particularly useful in itself.

> > completing MARID still exist so there's no point in spending a lot of time
> > on figuring out the technical points.
> 
> Moving hand over head.

I have no idea what that means, but that's probably OK.

Scott K

---

From: Dotzero <[email-masked]>
Date: Sat, 14 Apr 2012 20:07:50 -0400

> protocol and not particularly useful in itself.

I'm getting tired of repeating this, but PRA is BROKEN. Pick a domain
that has a naked "-all" - ibm.com for example. Create a message with a
Mail From and From purporting to be from ibm.com. Now add a Sender
field from a random domain that does not publish an SPF record (of any
sort). The PRA will be the random domain. What this means is that a
bad guy can consistently game PRA to get a neutral result by using
random non publishing domains. BROKEN!

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 Apr 2012 00:29:32 -0400

Dotzero wrote:

>>> Hector:
>>> Thats not a technical �opinion, but a policy mandate. �Should I

>> Scott:
>> It depends on what you mean by great. �PRA is useful if you are worried about
>> resent-sender forgery. �I am not. �Other than that, it just gives you a domain

> random non publishing domains. BROKEN!

You should be tired because this is not the premise for getting rid of 
it. However, it should be because that was the original 2006 issue 
with the integration of SPF with the PRA concept introduced by Microsoft.

No one has every stated, now these protocol say it is perfect or that 
it covers all cases.  Yet, there are those who stated with technical 
experience, there are PRA use cases where it works great. I believe it 
is when Resent-Sender is involved, and now that we have 6+ years of 
field testing, we should see what the actual payoff is or not and 
review the conflicts in detail, if any.

BTW, it should be noted the example with IBM.COM is probably not good 
because it has a SPF v1.0 policy statement and the PRA does not apply.

        "v=spf1 -all"

This basically states a corporate policy:

       NO EMAIL EXPECTED USING THE IBM.COM DOMAIN.

It is a clear legal corporate mandate statement that no one nor 
anything is expected use the IBM.COM domain for sending email, from 
anywhere and from anyone - No Exceptions.

Overall, the PRA does not apply here because any original submission 
SHOULD NOT ever exist with a IBM.COM in 5321.EHLO or 5321.MAILFROM or 
5322.FROM.   The 5322.Sender would not exist until a submission takes 
place and that submission should never happen.  A legacy spoofer 
(unintentional/random usage of IBM) and SPF faker (intentional 
facsimile to spoof) would never get entry when RFC4408 is 100% followed.

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 Apr 2012 00:47:21 -0400

> risks.  Our task is not to mandate it, but to enable it.

I think what is not understood is that companies that use a strong 
-ALL are also making legal disclaimers for tort claims.   Good 
examples are IBM.COM and ALTAVISTA.COM

IBM.COM has

Non-authoritative answer:
ibm.com text =

         "v=spf1 -all"

and ALTAVISTA.COM has even more explicit policy disclaimer and 
couldn't be even more clear what its corporate intent is with this domain:

Non-authoritative answer:
altavista.com   text =

         "All mail claiming to be from altavista.com is forged"
altavista.com   text =

         "v=spf1 
+exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all"
altavista.com   text =

         "This domain sends no email"
altavista.com   text =

         "Null SPF is for tracking purposes only"

If a system claims SPF compliance and its IGNORES the strong exclusive 
hard fail policies, and especially those that state a NO MAIL policy, 
is 10000% putting the system at legal risk.  Both IBM.COM and 
ALTAVISTA.COM would be exempt and indemnified from any tort or user 
harm claims stemming from an irresponsible SPF receiver continuing to 
pass on the user what is 100% known to a violation of the domain 
policy and potentially harmful mail.

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 Apr 2012 04:04:59 -0400

> that resent-sender is some particular domain.

Scott, by design, it is basically a sanity or double check when there 
is a pass because if the SUBMITTER SPF policy was violated at 5321, 
per spec, the receiver SHOULD reject the transaction and there would 
be no reaching of the DATA state in order to get the payload. Its a 
two step checking concept:

    http://tools.ietf.org/html/rfc4405#section-4.2

    Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD
    select the domain part of the SUBMITTER address value as the
    purported responsible domain of the message, and SHOULD perform such
    tests, including those defined in [SENDER-ID], as are deemed
    necessary to determine whether the connecting SMTP client is
    authorized to transmit e-mail messages on behalf of that domain.

[STEP 1 - ENVELOPE TEST, NO PAYLOAD]

    If these tests indicate that the connecting SMTP client is not
    authorized to transmit e-mail messages on behalf of the SUBMITTER
    domain, the receiving SMTP server SHOULD reject the message and when
    rejecting MUST use "550 5.7.1 Submitter not allowed."

[STEP 2 - PAYLOAD "DOUBLE CHECK" TEST]

    If the receiving SMTP server allows the connecting SMTP client to
    transmit message data, then the server SHOULD determine the purported
    responsible address of the message by examining the RFC 2822 message
    headers as described in [PRA].  If this purported responsible address
    does not match the address appearing in the SUBMITTER parameter, the
    receiving SMTP server MUST reject the message and when rejecting MUST
    use "550 5.7.1 Submitter does not match header."

The 2nd "double checking" step per se, is specifically encourage in 
this section and in the security section.  But if the failure does 
occur at step 1, then there is no payload checking need.  In addition, 
it should be noted that the the above 2nd check and action, presumes 
an advanced receiver with payload filtering hooks, shims and/or 
callouts before the DATA "End of Data" server response is issued. Just 
a reminder that acceptance is not desirable if there going to be a 
failure point.  The only solution to that is a DISCARD concept when is 
hinted/described in SenderID (4406) intro:

    This document describes a mechanism such that receiving Mail Transfer
    Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents
    (MUAs) can recognize mail in the above category and take appropriate
    action.  For example, an MTA might refuse to accept a message, an MDA
    might discard a message rather than placing it into a mailbox, and an
    MUA might render that message in some distinctive fashion.

---

From: Dotzero <[email-masked]>
Date: Sun, 15 Apr 2012 11:49:04 -0400

On Sun, Apr 15, 2012 at 12:29 AM, Hector Santos <[email-masked]> wrote:
> You should be tired because this is not the premise for getting rid of it.
> However, it should be because that was the original 2006 issue with the
> integration of SPF with the PRA concept introduced by Microsoft.
>
> No one has every stated, now these protocol say it is perfect or that it
> covers all cases.  Yet, there are those who stated with technical
> experience, there are PRA use cases where it works great. I believe it is
> when Resent-Sender is involved, and now that we have 6+ years of field
> testing, we should see what the actual payoff is or not and review the
> conflicts in detail, if any.
>

You seem to forget the appropriation of spf1 records for the use of senderid.

> It is a clear legal corporate mandate statement that no one nor anything is
> expected use the IBM.COM domain for sending email, from anywhere and from
> anyone - No Exceptions.
>
> Overall, the PRA does not apply here because any original submission SHOULD
> NOT ever exist with IBM.COM in 5321.EHLO or 5321.MAILFROM or 5322.FROM.
> The 5322.Sender would not exist until a submission takes place and that
> submission should never happen.  A legacy spoofer (unintentional/random
> usage of IBM) and SPF faker (intentional facsimile to spoof) would never get
> entry when RFC4408 is 100% followed.
>

"SHOULD NOT" does not mean "WILL NEVER" - bad people do bad abusive
things. I will also point out that I did not include EHLO or SUBMITTER
in my example. And I point out to you that RFC 4408 has nothing to do
with PRA.

The operative section of RFC 4407 (which DOES have something to do with PRA) is:

3. Select all the non-empty Sender headers in the message.  If there
      are no such headers, continue with step 4.  If there is exactly
      one such header, proceed to step 5.  If there is more than one
      such header, proceed to step 6.

So if their is a single non-empty Sender header then that will ALWAYS
be the PRA. This invites abuse when PRA can be set to any arbitrary
domain unrelated to the Mail From domain.

I

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 15 Apr 2012 13:51:33 -0400

On Sunday, April 15, 2012 04:04:59 AM Hector Santos wrote:
> > the body.  It could be anything.  I don't see any value in knowing before
> > DATA that resent-sender is some particular domain.
> 

Yes.  I've read the relevant RFCs and understand the design.  My feeling that 
they are pointless is not based on ignorance.  Here's an example for you:

5321.Mail From: good.example.com
4405.Submitter: bad.example.net

5322.From: good.example.com
5322.Resent Sender: bad.example.net

4407.PRA: bad.example.net

In this example the connecting IP address gets a pass result for 
bad.example.net and a fail result for good.example.com.

As the receiver is preparing to decide if they want to go to DATA or not they 
have two conflicting facts to consider:

1.  SPF (or SPF2.0/mfrom) fail result
2.  SUBMITTER pass result

How is this conflict to be resolved?  Reading RFCs won't explicitly help as 
none of them will tell you (thus my earlier point that there is no integrated 
protocol).  RFC 4405 says one should go to DATA and see if PRA and SUBMITTER 
match.  The inferred design here is "If submitter passes, ignore SPF".

If you support SUBMITTER, then you've handed everyone a chance to bypass SPF.

For this example, let's say we follow the advice of 4405 and go to data.  We 
can then determine that SUBMITTER and PRA match and the message gets a 
SenderID pass.  Then what?  You have a domain name from a header field that no 
one will see and isn't used for anything that was authorized.  To do anything, 
you'd still need to decide if this is a good domain or a bad domain (i.e. 
reputation system and "batteries required") since it's a domain name that's 
not related to anything in the message that users or operators see/use.

SPF and SenderID are by design incompatible.  SenderID can only work by 
ignoring SPF.  It is a happy coincidence that in the vast majority of cases 
they produce the same result, but that is not at all the same thing as having 
an integrated or interoperable design.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Apr 2012 05:43:26 -0400

Hi,

Thanks for your input.  Question, do you believe the WG should review 
the concerns and propose protocol corrections learned from 6+ years of 
field testing?

Thanks

---

From: Dotzero <[email-masked]>
Date: Mon, 16 Apr 2012 09:24:33 -0400

My understanding is that the WG focus is on updating 4408. If folks
want to do an additional document detailing the "experiment(s)", I
have no problem with that - but let's not confuse the two. Updating
SenderID (including PRA) was not part of the charter for this working
group (I will defer to the Chairs if they feel my statement is
incorrect) so why you keep on trying to drag it in-scope without a
re-charter is beyond me.

Mike

On Mon, Apr 16, 2012 at 5:43 AM, Hector Santos <[email-masked]> wrote:
> Hi,
>
> Thanks for your input.  Question, do you believe the WG should review the
> concerns and propose protocol corrections learned from 6+ years of field
> testing?
>
> Thanks
>
>
> --
> Hector Santos, CTO
>>> it.
>>> SHOULD

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Apr 2012 06:50:39 -0700

> Other than the fact that they're in separate documents, how are they different?

It is a value-add protocol that sits on top of DKIM.  As such, it counts as a
separate mechanism.  It deals with very different semantics than DKIM.

You are presumably in a building right now.  You rely on that building but you
are not "part" of it nor are you "similar" to it.  ADSP's relationship to DKIM
is the same as your relationship to the building.

In terms of "building upon", the Repute wg is "similar" to ADSP or DMARC, in
that it builds upon the authentication work of DKIM and SPF, but it is separate
work, not merely separate documentation.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Apr 2012 06:59:41 -0700

On 4/10/2012 4:47 PM, Scott Kitterman wrote:
> DKIM 
> signatures should survive forwarding, 

This being a technical discussion, please forgive my being picky about
vocabulary, but precision and accuracy in the discussion matter.

Per RFC 5598, "forwarding" is not the same as "relaying".  Relaying is what MTAs
do; they do not change the message.  Forwarding is what MUAs sometimes do, which
means re-posting a new message, usually with significant changes to the original
message.

DKIM is design to survive relaying.  Whether it survives "forwarding" depends on
what the MUA -- like a mailing list -- does in creating the new message.  On the
average, one should not expect a DKIM signature to survive forwarding.

The rest of your note makes clear that you meant all of the above; I really am
only being picky about the wording, not because your note seemed confused but
because so many people who discuss this topic often confuse relaying with
forwarding.

d/

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Apr 2012 07:02:27 -0700

On 4/14/2012 5:07 PM, Dotzero wrote:
> I'm getting tired of repeating this, but PRA is BROKEN.

I'm not understanding why this is being discussed now.  I thought this topic had
been dispatched some time ago.

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Apr 2012 07:04:20 -0700

> +1, and also +1 to the point that we don't want to start down the path of documenting everything SPF isn't.

+1

d/
-- 

  Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Apr 2012 11:09:40 -0400

> incorrect) so why you keep on trying to drag it in-scope without a

Because I don't agree and its doesn't make engineering sense to me 
that a charter with predetermined conclusions on a protocols fate 
where, as you suggest, is actually out of scope.  You can't have it 
both ways because you are for all intent and purpose telling 
commercial vendors to DROP something and the reasons are not sound. 
Its OUT OF SCOPE, but BTW we decided to KILL it.  That doesn't make 
sense to me.

And what is beyond me that all the 6+ years of Corporate marketing is 
just all of sudden - puff- LOST.

Can you tell me what will happen here?

http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx
 
http://www.microsoft.com/mscorp/safety/technologies/senderid/support.mspx

We we saying all these companies no longer support SenderID?

That is, quite frankly, is whats beyond me and quite frankly I serious 
think there is serious underestimating on the repercussions of the the 
desired abandonment without any real review as to why.

At the very least I am trying to get a focus on the issue based on 
technical merits of the original proposal, the IETF interest on its 
co-existence and the 6+ years of field testing experiment conclusions, 
not a false fallacy, extremely bias situation that a) its not in use, 
b) the original use cases are indeed invalid and c) what appears is a 
lack of understanding on it works in an integrated, excuse me, in 
"TANDEM" fashion/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Apr 2012 13:38:51 -0400

Colleagues,

Hat on.

> Its OUT OF SCOPE, but BTW we decided to KILL it.  That doesn't make

[. . .]
 
> We we saying all these companies no longer support SenderID?

[. . .]

> conclusions, not a false fallacy, extremely bias situation that a)
> its not in use, b) the original use cases are indeed invalid and c)
> what appears is a lack of understanding on it works in an
> integrated, excuse me, in "TANDEM" fashion/

I think we need to be clear on what we are asked to do.

First, we are asked to report on the experiment.  The conditions for
the experiment are not exactly clear, but the WG's experiment document
gives an interpretation.  If there is a clear disagreement with that
interpretation and an alternative approach for interpreting the
experiment, we did not receive a draft proposing it, despite having
asked for such a draft.  If, however, someone wants to produce a draft
with such an alternative intepretation and ask that it be considered
by the WG instead, then one is free to do so.  If one intends to do
that, it would be a good idea to do it as soon as possible, since we
seem otherwise to be converging rapidly on the conclusions in the
present WG draft.  Objections that do not propose specific changes to
the WG draft are not helpful in clarifying what needs to change.

Second, we are asked to create an update of SPF for the standards
track.  That action has nothing at all to say about other things in
the experiment.  The IETF is not the protocol cops, and there is no
reason whatever that we have to say anything about whether people
continue to use SenderID or any other technology.  The RFC series is
an archival series, and those experimental RFCs will persist even if
every single person participating in this WG thinks that they're bad
ideas.  

In conclusion, then,

    1.  if anyone disagrees with specific parts of the WG's experiment
    document, then send text;

    2.  if anyone disagrees with the foundational assumptions of the WG's
    experiment document, then propose an alternative.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Stuart D Gathman <[email-masked]>
Date: Mon, 16 Apr 2012 15:21:16 -0400

Long ago, Nostradamus foresaw that on 04/16/2012 11:09 AM, Hector Santos 
> just all of sudden - puff- LOST.
While Sender-ID hasn't gotten much use, my personal opinion is that it 
could get more use if the technical conflict with SPF (interpreting 
v=spf1 records as spf2.0/mfrom,pra) was formally fixed.  The technical 
conflict forces people to choose between the two protocols, rather than 
trying them both.  It is not too late to make that fix and compare SID 
with DKIM in practice.  Making that fix is out of scope for this WG, 
however.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Apr 2012 15:05:44 -0700

At 12:21 16-04-2012, Stuart D Gathman wrote:
>While Sender-ID hasn't gotten much use, my personal opinion is that 
>it could get more use if the technical conflict with SPF 
>(interpreting v=spf1 records as spf2.0/mfrom,pra) was formally 
>fixed.  The technical conflict forces people to choose between the 
>two protocols, rather than trying them both.  It is not too late to 
>make that fix and compare SID with DKIM in practice.  Making that 
>fix is out of scope for this WG, however.

I'll use the above as a basis for feedback.  I gather that most of 
the group agree that there is a technical conflict.  The next step is 
generally to agree on how to fix the technical conflict.  My co-chair 
posted a message about that ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01182.html 
).  I'll quote part of his message:

  "First, we are asked to report on the experiment.  The conditions
   for the experiment are not exactly clear, but the WG's experiment
   document gives an interpretation.  If there is a clear disagreement
   with that interpretation and an alternative approach for interpreting
   the experiment [is welcome]."

If the alternative is out of the scope of this WG, I cannot redefine 
the scope to fit that as it is beyond what I am allowed to do.  If an 
alternative has been proposed and you don't see someone commenting, 
it may be that people did not understand that the person was 
proposing an alternative.  Drop a note to the WG Chairs and one of us 
will ask you to clarify your proposal on this mailing list.  It may 
also happen that other people do not support the alternative.  It is 
up to the person proposing the alternative to reach out to other 
people and build support.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2012 23:00:31 -0000

In article <[email-masked]> you write:
>>fixed.

That would be something other than Sender-ID.  Nobody really knows why
Sender-ID didn't catch on, whether it was technical issues,
uncertainly about the patent license, general hostility to Microsoft,
or that people already had SPF and it was good enough.  (In the
absence of any data, I tend toward the last of those.)  Anyone who was
interested in Sender-ID has had the better part of a decade to invent
new versions, nobody has, and doing so now most definitely is not our
job.

To wrap up the experiment, we just need to write up a document that
says SPF has been widely adopted, Sender-ID hasn't, provide the
evidence, and leave it at that.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Apr 2012 16:19:09 -0700

+1

As much as it would be intellectually interesting to understand the 'why's of
these successes and failures, we are currently left with the mere reality of
them.  That's the best we can document, at this stage, absent funding, time,
research skill and quite a lot of energy.

d/
-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Apr 2012 16:19:26 -0700

On 4/14/12 7:45 AM, Alessandro Vesely wrote:
>>> The RFC5321<reverse-path>  is not bound to a specific ADMD which is
Agreed.
> will always be SPF-ignorant servers, and servers like gmail that check
Receivers have found the experimental SPF (lacking SRS) does not permit 
normal SMTP operation as defined in rfc5321 section 6.1 and rfc1123 
section 5.2.6.  Rejection based on SPF will burden customer support when 
valid email becomes lost.   Third-party domains should instead use SMTP 
compliant anti-phishing strategies, such as those found with DKIM, 
S/MIME, or OpenPGP.
> risks.  Our task is not to mandate it, but to enable it.
Agreed.  For example, this could be done using something as simple as 
incorporating the scope-ID used in RFC4406 to clarify applicable SMTP 
parameters with a list of EHLO / MFROM.  When the scope contains just 
EHLO, only then will SPF verification offer a means to "authenticate" a 
source.  EHLO also offers a safe means to ensure rejection will not 
interfere with normal SMTP operation.  Since bounce addresses are 
normally not visible and might be UTF-8 encoded, only EHLO parameters in 
conjunction with DKIM signature alignment offers a reasonable level of 
exploitation protection.  Of course, EHLO-only scopes should also 
exclude local-part macros.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 Apr 2012 19:31:52 -0400

Its unfortunate that a key point continues to be overlooked about 
SenderID.  SIDF was proposed to basically cover certain use cases that 
SPF v1.0 did not cover.  It was limited to possible use cases that fit 
within ~20% possible spectrum because it was measured early on ~80% of 
the transaction, the domains matched:

      5322.PRA == 5321.MAILFROM

and is why the 5321.SUBMITTER was proposed to optionally expose the 
PRA at 5321 as an optimization to avoid the payload and the 
accept/bounce potential.

Its is basically the similar issue as it was with DKIM where, in 
general, the 5321.MAILFROM only differs with list mail distributions.

You can measure at least one sum part of possible SENDERID client 
spectrum by seeing if they also support 4405 (SUBMITTER) and this is a 
high volume of transactions once your SMTP server enabled the 
SUBMITTER extension.

Usage measurement is wrong.  Its there, no doubt. If the SPFBIS is 
going recommend to end the  SIDF protocol, IMV, the WG's prudent 
engineering job should include the consideration whether there will be 
new harm with the lost of PRA/SUBMITTER value in certain use cases 
where the PRA/SUBMITTER domains are different then 5321.MAILFROM.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Apr 2012 16:56:17 -0700

At 16:31 16-04-2012, Hector Santos wrote:
>engineering job should include the consideration whether there will 
>be new harm with the lost of PRA/SUBMITTER value in certain use 
>cases where the PRA/SUBMITTER domains are different then 5321.MAILFROM.

I gather that the above is a suggested alternative.  That's covered 
by the "send text" mentioned by my co-chair at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01182.html

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Apr 2012 15:30:31 +0200

On Tue 17/Apr/2012 15:26:05 +0200 Douglas Otis wrote:
> parameters with a list of EHLO / MFROM.  When the scope contains just EHLO,
> only then will SPF verification offer a means to "authenticate" a source.

We cannot do that for this SPF version.  However, we could require that a
helo-pass prevents rejection.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2012 09:56:11 -0400

On Tuesday, April 17, 2012 03:30:31 PM Alessandro Vesely wrote:
> > EHLO,

No.  We could not.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Apr 2012 10:26:27 -0400

Dear colleagues,

No hat.

> > parameters with a list of EHLO / MFROM.

> helo-pass prevents rejection.

There are many things we could do to SPF.  I advise everyone
considering what they'd like SPF to look like to read the charter
carefully, however, because anything that isn't actually already
deployed _today_ or else a straightforward clarification is, in my
reading, not part of the scope of our work.  The above two examples
are picked more or less at random, and not with the intention of
picking on Doug or Alessandro.  I'm just urging that, if you have
things you want of SPF, you consider very carefully when you plan
those changes for consideration.  In many cases, it might be wise to
build up a list of desiderata for a subsequent effort.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Apr 2012 07:37:35 -0700

>> > helo-pass prevents rejection.

It might be worth our being clear about the reason we could not.

I believe the proposed "helo-pass prevents rejection" would qualify as adding
new functionality to spf and that there is not already wide deployment of it.
As such, it falls outside of the charter.

Does that match the reason(s) other folk see?

d/
-- 

   Dave Crocker

---

From: Dotzero <[email-masked]>
Date: Tue, 17 Apr 2012 10:44:47 -0400

+1

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2012 11:13:01 -0400

On Tuesday, April 17, 2012 07:37:35 AM Dave Crocker wrote:
> I believe the proposed "helo-pass prevents rejection" would qualify as
> adding new functionality to spf and that there is not already wide
> deployment of it. As such, it falls outside of the charter.
> 

There is a mention of this in RFC 4408 paragraph 9.3.3.2 as something one may 
do.  It does not how every describe the conditions under which doing so is 
appropriate.  I agree that absent evidence of wide spread deployment, 
promoting a may to a MUST is out of scope.  Even if it were in scope, it would 
still be a bad idea since it only works if the identity in HELO is trusted in 
some manner.

Adding Sender-ID scopes to SPF is clearly outside the charter.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2012 15:26:32 -0000

>Does that match the reason(s) other folk see?

Yes.  This is a cleanup pass, to make the documentation match what
SPF actually does.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 17 Apr 2012 17:46:58 +0200

+1

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Apr 2012 17:58:45 +0200

On Tue 17/Apr/2012 17:19:47 +0200 Scott Kitterman wrote:
>>>>> we could require that a helo-pass prevents rejection.
>>>
>>> No.  We could not.
>>
> appropriate.

Those conditions are introduced at the very beginning of section 9, namely to
ameliorate the fact that SPF is not compatible with SMTP.  It is not a new
functionality, anyway.

> I agree that absent evidence of wide spread deployment, promoting a may to
> a MUST is out of scope.

Section 9 is explicitly declared non-normative, so may-vs-must arguments have
little sense.  I claim this proposal is in scope because it is the correction
of an error, as it is obviously an error for a mail protocol to be
incompatible with SMTP.

> Even if it were in scope, it would still be a bad idea since it only works
> if the identity in HELO is trusted in some manner.

I'm not following you.  The correction doesn't imply whitelisting a specific
helo identity (that's mentioned in 9.3.3.1).  It relies on an SPF "pass"
result for the helo identity, with no trust implications whatsoever.

> Adding Sender-ID scopes to SPF is clearly outside the charter.

Yes.

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Apr 2012 11:58:06 -0400

Dave Crocker wrote:

>>> Alessandro:
>>> We cannot do that for this SPF version.  However, we could require 
>>> that a helo-pass prevents rejection.

> adding new functionality to spf and that there is not 
> already wide deployment of it. As such, it falls outside of 
> the charter.
> 

Not really, because its already in scope as a possible condition by 
implementations to consider the HELO SPF value.

The reason issue is essential a matter of trust and confidence values 
for the MAIL FROM vs HELO results.

The suggestion problem is that its can not be an a new functional 
requirement as you suggested, but one that would be in the form of an 
inherent HELO-PASS mandate for acceptance, essentially a White "Good 
Mail" filtering trump card over any other possible illogical condition 
or SPF failure.

Overall, the suggestion implies a SPF provision such as:

    SPF MUST NOT provide a mechanism that impugns the existence of
    non-first party MTA router authentication with a SPF HELO-PASS.
    A corollary of this requirement is that the protocol MUST NOT
    link practices of first party MAIL FROM domains with the
    practices of third party MTA router policies.

     INFORMATIVE NOTE: the main thrust of this requirement is that
     practices should only be published for that which the publisher
     has control, and should not meddle in what is ultimately the
     MTA router or local policy of the receiver.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2012 12:15:59 -0400

> result for the helo identity, with no trust implications whatsoever.

This is similar to my objection to SUBMITTER overriding Mail From.  Here's an 
example:

EHLO: bad.example.net
Mail From: good.example.com

Based on the published SPF records for both and the connect IP address, in 
this example, the SPF check for bad.example.net passes and the check for 
good.example.com fails.  If the EHLO result trumps the Mail From result, then 
malicious senders can trivially construct arbitrary hostnames and arrange for 
a HELO/EHLO pass result.

This is, without external information, indistinguishable from:

EHLO: relay.example.net
Mail From: good.example.com

This may be a transparent relay (AKA forwarder).

In order to let a pass HELO/EHLO result trump a fail Mail From result, you 
have to know and trust the host in question, otherwise you've just made SPF 
pointless.  This is NOT how SPF works today and changing it to work this way 
is completely out of scope.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Apr 2012 09:49:57 -0700

On 4/17/2012 7:26 AM, Andrew Sullivan wrote:
>   anything that isn't actually already
> deployed_today_  or else a straightforward clarification is, in my
> reading, not part of the scope of our work.

+1.

But to emphasize that a mere existence proof is not sufficient, the 
qualifier "widely" also applies.

The formal charter language is rather clear about this:
> Changes to the SPF specification will be limited to the correction
> of errors, removal of unused features, addition of any enhancements
> that have already gained widespread support, and addition of
> clarifying language.

/already/  and  /widespread/

For any suggestion to make /additions/ to the spfbis specification, I 
believe this means that the only reasonable response is:

      "Document where this is already in widespread use."

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Apr 2012 19:38:02 +0200

> Mail From: good.example.com

It would be similar if you had to validate the helo identity against some
value to be determined later examining the message content.

> good.example.com fails.

I'm not sure what you mean by "passes".  If bad.example.net passes, then the
server found the IP address of the connecting client in an SPF record under
that DNS label.  I'm not proposing "helo-neutral prevents rejection", but
helo-pass.

> If the EHLO result trumps the Mail From result, then malicious senders can
> trivially construct arbitrary hostnames and arrange for a HELO/EHLO pass
> result.

Yes, but since --as we discussed before-- they cannot realistically hope to
induce backscatter, they would easily obtain exactly the same result by
forging the Mail From in the same way as they forge EHLO.  It is not
difficult for a malicious sender to say:

EHLO: good.example.com

> This may be a transparent relay (AKA forwarder).

According to this proposal, we'd require that example.net define an SPF
record, under the label relay.example.net, where they authorize the IP
addresses that their relay uses.  This workaround might be acceptable
considering the many reasons why such kind of relaying/forwarding should not
be done.  The only clients that behave the way you exemplified are forwarders
who are unable to do better than that.  That workaround is good enough, as
long as we consider that publishing an SPF record for each relay has no
contraindications (which SRS and other solutions apparently have).

> pointless.

That would be true if I knew the Mail From.  Since I know neither, they are
equivalent.

> This is NOT how SPF works today and changing it to work this way is
> completely out of scope.

What I'm proposing to change is how it chokes, not how it works.  And
although it is a small fraction of cases, it generates so much noise as to
become a major hindrance to universal adoption of reject-on-fail.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Apr 2012 11:08:18 -0700

Dear Alessandro,

Disagree, but the inverse would be true.  EHLO identity based failure 
permits SMTP compliant rejection by SPF "-all" records.  The EHLO 
identity compliance provides a basis for a MUST REJECT requirement that 
avoids conflicts with existing use protected by existing standards.  
EHLO also offers safer DKIM domain alignments since both use A-labels.  
Asserting identity scopes in future record versions would ensure against 
possible misuse and prevent authorization escalating to authentication.

Regards,
Douglas Otis

---

From: Stuart D Gathman <[email-masked]>
Date: Tue, 17 Apr 2012 17:38:18 -0400

Long ago, Nostradamus foresaw that on 04/16/2012 07:19 PM, Douglas Otis 
would write:
> l'd instead use SMTP compliant anti-phishing strategies, such as those 
> found with DKIM, S/MIME, or OpenPGP.
> incorporating the scope-ID used in RFC4406 to clarify...
No SMTP features are broken unless a receiver rejects emails from their 
own "admin domain boundary" MTAs - which includes alias forwarders 
requested/authorized by the recipient.  An alias forward which the (end 
user) recipient did not authorize or request (even informally) is a 
forgery, plain and simple, and should be rejected.  It is a *limitation* 
of SPF that tracking said "boundary" MTAs can be difficult for public 
email providers (like gmail), which is why those public email providers 
tend not to reject on SPF fail (as they shouldn't).  However, smaller 
email domains that *do* track which forwarders are authorized get a lot 
of mileage out of rejecting SPF fail.

Statements like "SPF breaks forwarding" are made from the perspective of 
large public email providers, and are not strictly true - they are only 
true in practical sense and only if you happen to be a large public 
email provider (with a tiny percentage of email domains and large 
percentage of email traffic).

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Apr 2012 18:38:04 -0400

Stuart D Gathman wrote:
> Douglas Otis would write:

> percentage of email traffic).

+1.  People seem to forget the that majority of systems are the 
smaller sites and they are generally the targeted victims created by 
the operations of the smaller group of larger volume sites.

Domains like yahoo.com, hotmail.com, earthlink.com, aol.com, msn.com, 
compuserv.com and others and now gmail.com are extremely highly 
abusive, spoofed domains and the rest of the larger group of smaller 
sites are the victims.

I recall many years ago it was so bad, for a moment there we just just 
BLOCKED all these domains, unless it was an authenticated session and 
the user was allowed to use these domains as an author alias.  It got 
so bad, vendors could no longer just pass the buck to the operators 
and the competitive advantage was now offering both system and user 
level mail filtering.

So SPF and other ideas is not just about protected the the domain 
message, but also the RECEIVER system from ABUSE!  For the first time 
ever, section 7.8 was added to 2821BIS (5321) recognizing the problem 
receivers were facing:

    7.8.  Resistance to Attacks

    In recent years, there has been an increase of attacks on SMTP
    servers, either in conjunction with attempts to discover addresses
    for sending unsolicited messages or simply to make the servers
    inaccessible to others (i.e., as an application-level denial of
    service attack).  While the means of doing so are beyond the scope of
    this Standard, rational operational behavior requires that servers be
    permitted to detect such attacks and take action to defend
    themselves.  For example, if a server determines that a large number
    of RCPT TO commands are being sent, most or all with invalid
    addresses, as part of such an attack, it would be reasonable for the
    server to close the connection after generating an appropriate number
    of 5yz (normally 550) replies.

While I had recommended we needed the section recognizing pending 
payload based standards on the horizon, like DKIM/ADSP, the above 
statement

       "rational operational behavior"

was sufficient for providing SMTP receivers the idea of having a IETF 
protocol technical "legal" authorization for discarding mail and not 
some flimsy concept of "local policy always rules."

I guess because ADSP was still only a proposed standard, a normative 
reference could not be made for 2821BIS.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Apr 2012 17:30:27 -0700

On 4/17/12 2:38 PM, Stuart D Gathman wrote:
> Long ago, Nostradamus foresaw that on 04/16/2012 07:19 PM, Douglas 
> Otis would write:
>> l'd instead use SMTP compliant anti-phishing strategies, such as 
>> those found with DKIM, S/MIME, or OpenPGP.
> No SMTP features are broken unless a receiver rejects emails from 
> their own "admin domain boundary" MTAs - which includes alias 
> forwarders requested/authorized by the recipient.  An alias forward 
> which the (end user) recipient did not authorize or request (even 
> informally) is a forgery, plain and simple, and should be rejected.  
> It is a *limitation* of SPF that tracking said "boundary" MTAs can be 
> difficult for public email providers (like gmail), which is why those 
> public email providers tend not to reject on SPF fail (as they 
> shouldn't).  However, smaller email domains that *do* track which 
> forwarders are authorized get a lot of mileage out of rejecting SPF fail.
Dear Stuart,

This describes ad hoc out-of-band signaling not practical for email 
exchange protocols.  When users request email forwarding from Provider-X 
to Provider-Y, return-path/SPF rejection requires non-scalable 
arrangements to prevent loss of accepted email.   Only when the EHLO 
identity fails, is there evidence of forgery.  Loss of valid email is 
likely to prompt complaints for providers who reject email because 
return-paths referenced SPF records that can't possibly define 
"requested" forward-paths.  Such rejections break SMTP since this 
disrupts what many consider an essential SMTP function.  SRS had been 
the proposed solution never widely implemented, nor likely practical.
> Statements like "SPF breaks forwarding" are made from the perspective 
> of large public email providers, and are not strictly true - they are 
> only true in practical sense and only if you happen to be a large 
> public email provider (with a tiny percentage of email domains and 
> large percentage of email traffic).
Only SPF records referenced by EHLO provide source confirmations 
offering a suitable basis for acceptance or rejection.

Regards,
Douglas Otis

---

From: Stuart Gathman <[email-masked]>
Date: Tue, 17 Apr 2012 21:26:35 -0400

Long ago, Nostradamus foresaw that on 04/05/2012 01:50 PM, Alessandro
> addresses the users configured their forwarding recipe with.
Sorry, I meant case a.

> to ask and obtain authorizations, and have SPF records updated.
The authorization is informal, but it is authorized/requested.

> authorizations.  Records in such whitelists are inserted after a
That is only if you wish to automate formal authorization *and* check SPF.
> as appropriate.  That is SMTP-fictional, IMHO.
Yes, too much work at present, hence the correct thing to do, if you
wish to allow informal forwarding is not reject on SPF.

SPF has this limitation, but it does not "break forwarding" unless you
do it wrong.

---

From: Stuart Gathman <[email-masked]>
Date: Tue, 17 Apr 2012 21:41:59 -0400

Long ago, Nostradamus foresaw that on 04/17/2012 08:30 PM, Douglas Otis
would write:
> exchange protocols.  When users request email forwarding from
> Provider-X to Provider-Y, return-path/SPF rejection requires
> non-scalable arrangements to prevent loss of accepted email.   Only
> when the EHLO identity fails, is there evidence of forgery.  Loss of
> valid email is likely to prompt complaints for providers who reject
> email because return-paths referenced SPF records that can't possibly
> define "requested" forward-paths.  Such rejections break SMTP since
> this disrupts what many consider an essential SMTP function.  SRS had
> been the proposed solution never widely implemented, nor likely
> practical.
When I, as owner of the example.com domain, request (informally) that
someotherdomain.org forward to my example.com mailbox, there is
absolutely no problem for me, and the dozen or so other users of
example.com, to add such authorized forwarders to our company list.  If
our company grows, as long as its policy is always "all authorized
forwarders must be entered in the company authorized forwarder list or
risk rejection", there is no scalability problem.  It is only large
public email providers, like gmail, which have a problem with alias
forwarding, and it is easily solved by not rejecting on SPF fail. 

> offering a suitable basis for acceptance or rejection.
For gmail, perhaps - until they invent some magic way of divining likely
authorized forwarders from their huge user base.  For small domains like
the ones I operate, you are wrong.  SPF fail on MFROM *is* a suitable
bases for rejection, because I (and the other users) have listed (and
hence exempted) all authorized alias forwarders.  I reject 10000s of
forgeries daily that are sent to our tiny email domain.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2012 22:16:46 -0400

On Tuesday, April 17, 2012 09:41:59 PM Stuart Gathman wrote:
> authorized forwarders from their huge user base. 

FWIW, it appears they've done this.  If you publish a DMARC record (dmarc.org) 
and examine the Gmail feedback, mail they believe was forwarded (relayed) is 
marked as such.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 18 Apr 2012 16:20:27 +0200

On Wed 18/Apr/2012 16:00:13 +0200 Stuart Gathman wrote:
> on 04/05/2012 01:50 PM, Alessandro Vesely would write:

I don't see that.  Assume you're the owner of example.com.  I'm a user of
yours and also have a mailbox at someotherdomain.org.  They let me enter a
forwarding recipe from there to my mailbox at your domain.  If they are
clever, they check that I can get mail destined to that target address.
When would they ask you, formally or not?

>> That is SMTP-fictional, IMHO.

I think that's the case that John characterized as a "growing niche".

If we discard the proposed "helo-pass prevents rejection", the SMTP
compatible alternative that we're left with is to prevent rejection
altogether --that's what gmail does, btw.  Isn't that an even more drastic
change?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 10:30:07 -0400

> altogether --that's what gmail does, btw.  Isn't that an even more drastic

It's not a change.  RFC 4408 doesn't say reject or don't reject.  What the 
receiver chooses is not part of the protocol, only the mechanism for the 
choice (which is why there is If reject then ... language).

Scott K

---

From: Dotzero <[email-masked]>
Date: Wed, 18 Apr 2012 10:32:38 -0400

> choice (which is why there is If reject then ... language).

+1 - Too many people focus on reject as the only answer. As Scott
points out, this is not what RFC4408 says.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 18 Apr 2012 17:05:33 +0200

> choice (which is why there is If reject then ... language).

I'm not interested in wording at this stage.  Let's consider the overall
meaning of what we're going to say.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 11:24:46 -0400

> meaning of what we're going to say.

I propose we not say stuff about receiver policy that RFC 4408 doesn't say.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Apr 2012 16:11:12 +0000

> Sent: Wednesday, April 18, 2012 8:25 AM
> To: [email-masked]
> Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo identities
> 
> > > It's not a change.  RFC 4408 doesn't say reject or don't reject.
> > > What the receiver chooses is not part of the protocol, only the
> > > mechanism for the choice (which is why there is If reject then ... language).
> >
> > I'm not interested in wording at this stage.  Let's consider the
> > overall meaning of what we're going to say.
> 

+1.

-MSK

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 18 Apr 2012 12:54:27 -0400

Long ago, Nostradamus foresaw that on 04/18/2012 10:20 AM, Alessandro 
> When would they ask you, formally or not?
If you expect to get your mail addressed to someotherdomain.org at your 
example.com mailbox (which I run in your example), *you* need to tell me 
so I can add someotherdomain.org to the authorized forwarder list (or 
you can do it yourself - as a small domain, I gave you and other users 
access to tools to do so should you be interested).

If someotherdomain.org publishes an SPF record, that is the end of the 
story (unless they relay a lot of spam and I have to block them).  If 
they don't publish an SPF record, I have to put my mail admin hat on and 
go over logs to figure out a reasonable local SPF record (i.e. not an 
official SPF record, but one my mail servers use for that domain) that 
covers IPs someotherdomain.org sends from.  For an alias forwarder, that 
usually ends up being something like "v=spf1 ptr:someotherdomain.org -all".

On the other hand, if somejerkdomain.org decides to start alias 
forwarding some random mailbox "for your convenience" that you have no 
knowledge of, that is *forgery*, and will get rejected (and the IP 
banned if persistent) for any domain I administer if the sender 
published an SPF record with -all (which thankfully for banks and credit 
card companies, they generally do).

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Apr 2012 13:49:13 -0700

Dear Scott,

It would be appropriate to assert "should reject" for SPF failures 
referenced by the EHLO identity, and "should not reject" when referenced 
by the bounce address.

In other words, SPF can assure hop-by-hop path authentication when 
referenced by the EHLO.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 16:57:20 -0400

> In other words, SPF can assure hop-by-hop path authentication when

Do you have evidence this is in widespread use?  If not, it's outside the 
scope of the charter, IMO.

Scott K

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 18 Apr 2012 17:14:12 -0400

Long ago, Nostradamus foresaw that on 04/18/2012 04:49 PM, Douglas Otis 
would write:
>>>> What the
> referenced by the EHLO identity, and "should not reject" when 
> referenced by the bounce address.
>
+1 for SHOULD reject on EHLO fail  -  I've been doing that for years.  
Any MTAs that had problems had *many* problems due to general 
cluelessness.  I did talk to a mail admin who insisted on using the same 
EHLO name for all of his (dozen or so) MTAs, and the IP of the name did 
not match any of them (and he was not open to listing multiple IPs for 
the name in DNS), and the SPF record was for a MFROM which (for some 
reason) used a completely different set of servers, and he was mad at me 
for checking SPF for his EHLO and rejecting his connections.  I don't 
think his policies were very RFC compliant.

In fact, I would love it if SMTP were updated to "SHOULD reject when 
connect IP != EHLO FQDN IP" - no SPF is required.   But people have been 
abusing EHLO for years (not using a FQDN that matches the connect IP), 
and publishing an SPF record for EHLO makes it crystal clear that you do 
it right and EHLO forgeries should be rejected.

-1 for SHOULD NOT reject on MFROM unless qualified by "from an 
authorized (by the recipient) alias forwarder".

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Apr 2012 14:34:56 -0700

Dear Scott,

SPF RR referenced by bounce addresses must consider usage as this 
element might be modified during exchanges between administrative 
domains.  Those referenced by the EHLO however pertain to a single 
administrative domain publishing their own SPF RRs.  For receivers 
expending resources to process EHLO referenced SPF RRs, describe a 
scenario where it would be wrong to reject messages where EHLO/SPF 
fails.  Logically it should not matter whether there is only one or 
millions of administrative domains publishing SPF RRs for their own EHLO.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2012 18:03:48 -0400

Douglas Otis <[email-masked]> wrote:

>>>>>>> altogether --that's what gmail does, btw.  Isn't that an even
>more
>>>>>>> drastic
>>>>>>> change?
>What
>>>>>> the
>>>> I propose we not say stuff about receiver policy that RFC 4408
>doesn't
>>>> say.
>>> Dear Scott,
>>>
That's theorizing, not providing evidence of use, so it's not what the charter requires.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Apr 2012 17:25:54 +0200

On Thu 19/Apr/2012 16:51:23 +0200 Stuart D Gathman wrote:
> on 04/18/2012 10:20 AM, Alessandro Vesely would write:
>
>> I don't see that.  Assume you're the owner of example.com.  I'm
>> a user of yours and also have a mailbox at someotherdomain.org.
>> They let me enter a forwarding recipe from there to my mailbox at
>> your domain.  If they are clever, they check that I can get mail
>> destined to that target address. When would they ask you,
>> formally or not?
>
> If you expect to get your mail addressed to someotherdomain.org at
> your example.com mailbox (which I run in your example), *you* need to
> tell me so I can add someotherdomain.org to the authorized forwarder
> list (or you can do it yourself - as a small domain, I gave you and
> other users access to tools to do so should you be interested).

Fair enough.  That explains it perfectly clear, thank you.  In one
sentence, I'd summarize that as

   A mail server who opts to reject on fail needs to track all
   forwarders and whitelist them.

I don't mean to propose that wording for a document, just to make the
point clear.  From such statement, the responsibility for breaking
mail delivery seems to stay on the receiver who missed to track a
forwarder.

> they don't publish an SPF record, I have to put my mail admin hat on
> and go over logs to figure out a reasonable local SPF record (i.e. not
> an official SPF record, but one my mail servers use for that domain)
> that covers IPs someotherdomain.org sends from.  For an alias
> forwarder, that usually ends up being something like "v=spf1
> ptr:someotherdomain.org -all".

That looks like a whitelisting technique.  You could use any other
authentication method, e.g. DKIM, depending on the forwarder and the
amount of cooperation they are willing to put into it.

OTOH it is yet another use of SPF: for whitelisting.

> published an SPF record with -all (which thankfully for banks and
> credit card companies, they generally do).

For example, if you happen to write an I-D and publish it on the IETF
site, you would get mail redirected to the address used in the I-D.
That feature is probably written and fully explained somewhere, but
you might happen to have missed it.  If the original sender publishes
a strict SPF policy, you would reject the forwarded message.  Would
that be your fault, then?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Apr 2012 17:35:00 +0200

On Thu 19/Apr/2012 17:31:07 +0200 Stuart D Gathman wrote:
> on 04/18/2012 04:49 PM, Douglas Otis would write:
>>
> cluelessness.  I did talk to a mail admin who insisted on using the
> same EHLO name for all of his (dozen or so) MTAs, and the IP of the
> name did not match any of them (and he was not open to listing
> multiple IPs for the name in DNS), and the SPF record was for a MFROM
> which (for some reason) used a completely different set of servers,
> and he was mad at me for checking SPF for his EHLO and rejecting his
> connections.  I don't think his policies were very RFC compliant.

+1 as well.  (Note that a receiver has to check the helo identity
before it can see whether it fails, which is already a SHOULD.)

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2012 12:01:28 -0400

>    forwarders and whitelist them.

Hasn't that been the case - for any system with mail filtering methods?

The one thing to remember is that BAD GUYS do not complain -  only 
GOOD GUYS.  From our experience, it happens but very rare which, for 
the most part, justifies the actions because the payoff is high to 
reject the bad guys with zero-false positive rejects.

Nonetheless, there are people do use either SPF wrong or specific 
streams are being sent to a host for relaying and real false positives 
occur.  But in our experience, you whitelist them as they are 
reported.  Rest assured, if this was a BIG problem or just bothersome, 
I would never had supported SPF and doubt it would of gotten wide 
support.  But the fact is, at least in our experience and lack of 
reports from customers experience, its a rare issue.

Also it doesn't pay to get into the blame game - just tell them to 
whitelist whoever the "important" sender that is failing and problem 
solved.  There have been many customers that had problem and just 
turned SPF off or another filter off and almost always the spams 
always went up and they turned it back on, but paid attention in fine 
tuning the settings and doing a lot more in the area of whitelisting.

One tip which has proved very useful.

For our system, we have an auto white listing method where if the site 
account users sends out email to people, the expectation is that they 
known the target address and the target address is auto white listed 
for the FROM::TO pair.

So when I did my first offlist email to you, your address was 
automatically whitelisted   and the SPF, GREYLISTING crap is skipped!

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 16:39:59 +0000

> Sent: Thursday, April 19, 2012 8:26 AM
> To: [email-masked]

For this to appear in a standards document, you'll need to categorize exactly how one would identify a forwarder in a reliable way.

Mostly though it seems like we're hinting at some heuristics to improve on SPF's general accuracy.  I suspect a collection of these might be useful to document someplace but I'm skeptical about putting them in SPFbis itself (though see also my suggestion about appendices and a separate operations document).

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 12:45:41 -0400

On Thursday, April 19, 2012 04:39:59 PM Murray S. Kucherawy wrote:
> > Of Alessandro Vesely Sent: Thursday, April 19, 2012 8:26 AM
> > To: [email-masked]
> > Subject: Re: [spfbis] #12: RFC 4408 Section 9 - Forwarding and helo
> > identities> 
> For this to appear in a standards document, you'll need to categorize
> exactly how one would identify a forwarder in a reliable way.
> 
> Mostly though it seems like we're hinting at some heuristics to improve on
> SPF's general accuracy.  I suspect a collection of these might be useful to
> document someplace but I'm skeptical about putting them in SPFbis itself
> (though see also my suggestion about appendices and a separate operations
> document).

It's in RFC 4408 9.3.3.1 already.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2012 16:47:41 -0000

>> +1 for SHOULD reject on EHLO fail

Absolutely not.  The SPF spec is about how you come up with an SPF
result given envelope information.  It does not say anything about
what you do with the result.  Should this group be so ill-advised
as to start putting MTA design advice into 4408bis, I doubt that I
would be the only one to object.

Since the charter makes it abundanrly clear that we're not going to do
that, I will stop saying anything more on this topic, and I really
wish that other people would, too.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2012 13:04:47 -0400

> would be the only one to object.

Hmmm, but you always did object since day one.  The SPF specs was 
always very clear about actionable recommendations:

     SHOULD REJECT ON A DOMAIN POLICY HARDFAIL (-ALL)

We know you and others in the same camp didn't like that, believing 
domains didn't know what they were doing since day one, but the super 
vast majority disagreed and SPF was wildly and widely endorsed and 
deployed with the REJECT-ON-FAIL logic despite the MX receiver 
possibly forwarding the mail to outside its network.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Apr 2012 13:16:57 -0400

No hat.

Please forgive the intrusion by someone who doesn't know anything, but

>     SHOULD REJECT ON A DOMAIN POLICY HARDFAIL (-ALL)

I am unable to find in section 2.5, "Interpreting the result", of RFC
4408 the idea of a policy hardfail.  Maybe you mean "Fail", section
2.5.4.  If so, then that section is not consistent with what you say.
It says this:

   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.

There is no SHOULD there, and there is no RFC 2119 language at all.
This is, according to that text at least, purely a matter of local
policy.

Now, with my chair hat on (I haven't discussed this with SM, but it's
not like he hasn't said similar things recently):

Unless I see some argument _based on the text in RFC 4408_, and
quoting it, that any of this rejection stuff is in fact on-charter, I
have to ask people to stop discussing it.  Our charter is very clear:
we need to alter the specification as little as possible except to
clarify things, and to specify widely-adopted variations (either
explaining widely-adopted features or leaving out unused things).  In
effect, changes should be uncontroversially rooted in empirical data.
Since there is, AFAICT, empirical disagreement about what people are
doing, SHOULD reject is a modification of the protocol and won't meet
the test.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2012 18:15:18 +0000

> Sent: Thursday, April 19, 2012 10:17 AM
> To: [email-masked]

I checked all the way back to the original Meng Weng Wong document (thanks for the link, Scott).  Rejection on fail was never a MUST or even a SHOULD.

SPF is input to local policy only.  It could be one's local policy to do exactly what SPF says, and it may even be almost doctrine for some people that the whole Internet should work that way, but that's not what the document has ever said.

The same goes for DNSBLs (RFC5782) and ADSP (RFC5617).  DKIM even goes the opposite way, saying a failed signature isn't grounds for rejection.

-MSK

---

From: Commerco WebMaster <[email-masked]>
Date: Thu, 19 Apr 2012 13:55:19 -0600

> The same goes for DNSBLs (RFC5782) and ADSP (RFC5617).  DKIM even goes the opposite way, saying a failed signature isn't grounds for rejection.

True.  What is actually done with any email message received at the 
receiver end is (rightly so) really up to the receiver.  That said, 
there is an expectation that basic SMTP standards are being followed.

 From an SPF RR publisher's point of view, I think that there are really 
two major SPF behavioral cases which are generally hoped for and indeed, 
from experience, generally work well in SPF.

In the first case, if a publisher states that a domain under the 
publisher's control is not a sender of email - [e.g., example.com 
publishes TXT "v=spf1 -all"] - then the publisher has done their job 
saying that the domain, under the publisher's control, does not send email.

Logically, if a receiver is SPF aware and respects what SPF is all 
about, then the receiver of a message (who actually checks for an SPF 
TXT/SPF RR) probably wants to destroy that message as soon as possible, 
because, as per the domain name publisher, it is bogus.  However a 
receiver can do as they choose with the message, as long as, if their 
receiving software is SPF aware, that they never deliver it to the 
recipient with the publisher's domain name, as it damages the reputation 
of the publisher's domain name, which is why publishers elected to 
publish the DNS record in the first place.

In the second case, if a publisher states that a domain under its 
control [e.g., example.net] is a sender of email - [e.g., TXT "v=spf1 
ip4:192.168.123.10 ip4:192.168.111.20 -all"] - or other domains under 
the publisher's control have included another domain the publisher uses 
to send its messages [e.g., the case of example.org publishing TXT 
"v=spf1 include:example.net -all"] - then the publisher hopes the 
receiver will accept the message and process it in whatever way the 
receiver chooses to do so (e.g., checking for spam, virus checks, SMTP 
and other BL checks, etc).

Again, logically, in this case, the receiver has the power to deliver 
the message after whatever predetermined steps are taken or not taken 
after receiving the message.  As a publisher, we don't care at that 
point, except obviously, at the time of the SMTP exchange, to be told if 
the message was accepted for delivery or not (and just as obviously, if 
not, why not).

We are all painfully aware that the above logic won't work in some 
specific situations (e.g., some forwarding cases), but in most cases, it 
will work just fine (and has for many years at least around here).

Alan M.

---

From: Stuart D Gathman <[email-masked]>
Date: Thu, 19 Apr 2012 17:47:32 -0400

Long ago, Nostradamus foresaw that on 04/19/2012 11:25 AM, Alessandro 
> mail delivery seems to stay on the receiver who missed to track a
Yes, you get what I've been trying to say.  Someone else complained that 
"forwarder" has to then be defined, but it is the recipient that defines 
it, not the RFC.  It the recipient email admin  hates alias forwarders 
and is an activist, he can refuse to whitelist anyone and always reject 
on FAIL.  That doesn't help the SPF cause, because senders are tempted 
to try and work around this on their end.  One technique that I played 
with was using exists: to verify a BATV style MFROM signature - this 
goes through alias forwarders just fine with 100% accuracy.  But imposes 
a higher DNS overhead.

> amount of cooperation they are willing to put into it.
True.  The key is that you don't want to manually maintain a list of 
IPs.  Either SPF or DKIM would work for the purpose.  I would find it 
odd, however, if a forwarder went to effort of DKIM signing alias 
forwards, when rewriting MFROM would be much cheaper and easier.
> that be your fault, then?
Probably, since I am implicitly authorizing the alias forward by 
submitting the I-D.  But IETF really ought to be using "webmail" 
semantics and rewriting MFROM for that application.  (Are you sure they 
don't?)

---

From: Stuart D Gathman <[email-masked]>
Date: Thu, 19 Apr 2012 17:52:05 -0400

Long ago, Nostradamus foresaw that on 04/19/2012 05:47 PM, Stuart D 
Gathman would write:
> Yes, you get what I've been trying to say.  Someone else complained 
> that "forwarder" has to then be defined, but it is the recipient that 
> defines it, not the RFC.  It the recipient email admin  hates alias 
> forwarders and is an activist, he can refuse to whitelist anyone and 
> always reject on FAIL.  That doesn't help the SPF cause, because 
> senders are tempted to try and work around this on their end.  One 
> technique that I played with was using exists: to verify a BATV style 
> MFROM signature - this goes through alias forwarders just fine with 
> 100% accuracy.  But imposes a higher DNS overhead.
This is the killer app for the localpart macro that Doug Otis hates.  It 
enables SPF to pass through alias forwarding with no issues - except 
that DNS caching is defeated.

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2012 18:32:13 -0400

This is EXACTLY one of the concerns about the establishment of this 
SPFBIS that pitted the differences between those that used SPF in 
strong deterministic manner with those who wanted HEURISTIC or 
REPUTATION, including overall pushing the solution to DKIM.  It was 
the central issue back then when CSV/DNA was also a proposal on the 
MARID table - but dropped and it remained throughout the years with 
the same people MILITANTLY against SPF now in control of the 
specification.

Since day one, SPF was about rejection the abusive domain spoofer 
which was the #1 problem and still is.  The permissive authorization 
to SHOULD REJECT is pretty clear in section 2.5.4

2.5.4.  Fail

    If the checking software chooses to reject the mail during the SMTP
    transaction, then it SHOULD use an SMTP reply code of 550 (see
    [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
    (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
    The check_host() function may return either a default explanation
    string or one from the domain that published the SPF records (see
    Section 6.2).  If the information does not originate with the
    checking software, it should be made clear that the text is provided
    by the sender's domain.  For example:

        550-5.7.1 SPF MAIL FROM check failed:
        550-5.7.1 The domain example.com explains:
        550 5.7.1 Please see http://www.example.com/mailpolicy.html

I really and sincerely really HOPE that the cogs in charge QUIT trying 
to change the framework.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Apr 2012 18:40:41 -0400

Hector,

You are arguing that someone is taking over and changing something, but the 
words you want have never been in any SPF draft.  Continuing not to say what 
has never been said is not a change.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2012 18:59:47 -0400

> has never been said is not a change.

SOFTFAIL has a SHOULD NOT. NEUTRAL says nothing other than treat it as 
a NONE.

For FAIL, the backend has two chooses

     - mark it
     - reject it

If you choose to reject, you SHOULD use 550.

How can this any more clear?

Maybe the problem is what does "mark it" means?  I suggest its 
generally some formm of negative classification and stream splitting 
that doesn't HARM the users.  That could be a SPAM BIN folder on the 
online MUA, but for those that don't split or worst for the OFFLINE 
MUA POP3 user - they are hosed, they are harmed and the only real 
backend "choosing" is to REJECT.  Either way - you need to mark/reject 
the messages, and thats pretty clear.

Its peppered in many areas and it wasn't too hard to find:

RFC4406 (SenderID) also has it explicitly stated:

5.3.  Fail

    When performing the Sender ID test during an SMTP transaction, an MTA
    that chooses to reject a message receiving this result SHOULD reject
    the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error,
    where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced
    with the additional reason returned by the check_host() function, and
    "zzz" is replaced with the explanation string returned by the
    check_host() function.

And also RFC4405 (Submitter)

    4.2.  Processing the SUBMITTER Parameter

    ...

So please, lets get real about it.  This is exactly what I felt will 
happen with the relaxation of entire SPF/SIDF framework.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Apr 2012 19:26:06 -0400

Hector,

Two things.

> Since day one, SPF was about rejection the abusive domain spoofer

The section that you quoted simply does not say, in English, that SPF
is "about rejection" of anything.  That is,

> to SHOULD REJECT is pretty clear in section 2.5.4

it does _not_ say "SHOULD REJECT".  It says that if you choose to
reject, then you SHOULD use SMTP reply 550.  There is no sense

>    (DSN) code (see [RFC3464]), in addition to an appropriate reply text.

I urge you to read RFC 2119 and understand what SHOULD means, because
the 4408 text does not say what you insist it says.

Therefore, with my mailing list moderator hat on, unless you have
another piece of text from RFC 4408 to point to, this discussion is
off-charter and closed.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Apr 2012 16:37:28 -0700

On 4/19/12 2:52 PM, Stuart D Gathman wrote:
> This is the killer app for the localpart macro that Doug Otis hates.  
> It enables SPF to pass through alias forwarding with no issues - 
> except that DNS caching is defeated.
Dear Stuart,

Such local-part forwarding schemes would be accepting email based on 
unverified SMTP Mail parameters.  Mail parameters are fully open to 
exploitation, where validation independent of source would cause more 
harm than good.  The SMTP EHLO parameter is fully within the control of 
sending domains and independent of forwarding conventions.

Based upon the amount of heat versus light regarding Mail and EHLO, it 
could be beneficial to include a section explaining differences in dry 
sanguine terms.  This might be a simple outline describing factors that 
permit increased rejection compliance without use of ad hoc information, 
for example.  Some heavily phished domains are considering use of SPF as 
a fall-back strategy for when DKIM fails, which occurs in about 2% of 
the cases.  A scheme that only works for 98% of the valid mail stream 
will generate too many support calls for most operations.

In this application, EHLO offers several security related benefits:
   1) Greater chance of EHLO/SPF rejection with "-all" records.
   2) DKIM and EHLO both offer A-labels for easier domain alignment 
assessments.
   3) Fewer DNS transactions required.
   4) Will not interfere with SMTP forwarding features.
   5) Offers a safer basis for white-listing.
   6) Results in smaller tracking databases.
   7) Permits rejection prior to Data (compared with DKIM).
   8) Will not flood DNS cache with local-part foo.
   9) Permits easier to manage server specific RRsets.
10) Identifies providers willing to be directly accountable.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2012 19:49:20 -0400

This is semantics, and one where chair filtration is being unfairly 
used to PUSH a view and new framework by the editor that was clearly 
never there.  Sure, its always local policy, but its been clear and 
described in many parts of all the SPF/SIDF related documents what the 
very essence and intent of the deterministic SPF protocol was all 
about which WAS NOT about heuristics or reputation.

The list is too long to repeat all the text in all the docs which can 
summarize that for the HARDFAIL you either mark or reject it and the 
rejection you SHOULD use 550 - which is permanent.

So if anything, perhaps a new issue should be added that will define 
what "mark it" means.  Is that just adding the 5322.Receiver-SPF: FAIL 
and doing no more?  Fine. But practically reality suggest its 
separating it from the user's normal stream of new mail. But at SMTP, 
REJECT-ON-FAIL is in the specification and it always has been and that 
comes in the form of a SHOULD 550 - a permanent REJECT.

Marking this subject off-topic is fine be me because hopefully it will 
stop the attempts to change the meaning of what SMTP-SPF receivers are 
AUTHORIZED to do - per specification.

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2012 20:08:00 -0400

> the 4408 text does not say what you insist it says.

Its funny, because I have some doubt you may have the wrong 
interpretation yourself. But who knows.  One thing for sure, the 
attempt to change it with rfc2119BIS - failed!

On the one hand, some view it a SHOULD is really a MUST unless there 
are no workarounds and other hand, some view it has an OPTION, abeit 
strong recommendation to follow.

Either way, lets not forget to review 
http://tools.ietf.org/html/rfc2119#section-6

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Apr 2012 11:20:53 +0200

On Fri 20/Apr/2012 11:09:12 +0200 Scott Kitterman wrote:
>>> From: ietf.org On Behalf Of Alessandro Vesely
>>

IMHO, there is lots of room for progress there.  For one thing,
forcing users to repeat the same assertion twice is annoying and leads
to inconsistencies.

> It's in RFC 4408 9.3.3.1 already.

Besides that paragraph's wording and position, the fact that such
operations are to be carried out manually determines an unfair bias
against low-volume senders.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Apr 2012 11:22:39 +0200

On Fri 20/Apr/2012 10:13:04 +0200 John Levine wrote:

> what you do with the result.

John,
RFC 4408 says:

  if a claimed identity fails verification, local policy can take
  stronger action against such E-Mail, such as rejecting it.

Yeah, it doesn't say CAN take action, but do we think reject-on-fail
is not an integral part of SPF?

> Should this group be so ill-advised as to start putting MTA design
> advice into 4408bis, I doubt that I would be the only one to
> object.

As ill-advised as putting that kind of advice may be, it is even worse
to write it in a form so concealed and reticent that makes it hard to
even comprehend what the intended meaning might be.  Remember the ADSP.

I agree that 2119-language is not appropriate for wording this kind of
advice.  Nevertheless, we HAVE TO spell it loud and clear, as it would
be hypocritical and error-prone to refer readers to some unwritten
text in order to learn the difference between -all and ~all.

> Since the charter makes it abundantly clear that we're not going to do

Please, can we avoid these meta arguments?  Servers misbehavior based
on possible misunderstandings of the spec /is/ an issue, and the
charter keeps clear from prohibiting to clarify it.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Apr 2012 11:32:14 +0200

On Fri 20/Apr/2012 10:39:03 +0200 Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Andrew Sullivan
>
> I checked all the way back to the original Meng Weng Wong document
> (thanks for the link, Scott).  Rejection on fail was never a MUST
> or even a SHOULD.
> 
> SPF is input to local policy only.  It could be one's local policy
> to do exactly what SPF says, and it may even be almost doctrine for
> some people that the whole Internet should work that way, but
> that's not what the document has ever said.

Did you manage to find out /who/ said it, then?

> The same goes for DNSBLs (RFC5782) and ADSP (RFC5617).

I wouldn't consider those a shining example of clarity.

> DKIM even goes the opposite way, saying a failed signature isn't
> grounds for rejection.

Correct, DKIM does the authentication part only.  That is covered by
TCP for SPF concerns.

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2012 12:44:23 -0000

>is not an integral part of SPF?

Reject on fail is not an integral part of SPF.  Many mail systems use
it in other ways, such as an input to a scoring system, or to manage
whitelisting.

In this case, you are just wrong.  Please stop.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Apr 2012 10:04:18 -0400

Dear colleagues,

Moderator hat on.

> is not an integral part of SPF?

I've already posted, several times, that anyone who wants to make this
argument any more MUST provide a reference to text in RFC 4408 that
clearly states something stronger than the local policy text already
discussed.  The alternative of empirical evidence that one local
policy is universally used is already ruled out by the evidence so far
presented.  

Unless you have an argument that is tightly bound to actual text in
RFC 4408 and that shows something stronger than the local policy
option that has been so far discussed, do not post on this topic.  It
is closed.  People are no longer posting new arguments, and there is
nothing more to discuss.  Continued repetition of the same arguments
will be treated as the disruptive behaviour that it is becoming.

Thanks,

A 

-- 
Andrew Sullivan
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Sun, 22 Apr 2012 09:58:09 -0400

> If the SPFBIS is going recommend to end the  SIDF protocol

Let's be clear about one thing here: while "ending the SIDF protocol" might
be something some participants in this WG want to do, it is not a goal of
the WG, and as far as I can tell, no one is trying to put that in any of
the WG's documents.  The working group is chartered to describe its
consensus of the result of a number of years of experimentation with SPF
and SIDF, and to move SPF to Proposed Standard.  If that consensus says
that SPF is in wide use and SIDF is not, and there's data to support that,
it's fine.

As an AD, I will say that if any document comes out of this working group
making any normative statement (or even a strong recommendation) telling
people NOT to use SIDF, saying that SIDF is deprecated or obsolete,
obsoleting any SIDF RFC, or moving any SIDF RF to Historic, I will surely
put a DISCUSS position on that document for exceeding the WG's charter.
 I'm guessing that Pete, who's the responsible AD here, will cut it off
before it ever gets to me anyway, should a document do that.

So, please, everyone stop accusing the WG of trying to "kill" SIDF.  It
will not.  If someone should want to create an SIDFbis WG to do something
one way or the other with that protocol, that'd be a fine thing to pursue
as a separate effort.  But later, after this one is done.

Barry

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Apr 2012 16:12:26 -0400

(offlist)

Hi Barry,

What bothers me that statements were written with a principle focus to 
replace SIDF with DKIM and there obvious issues that I believed where 
simply wrong from many angles I don't wish to repeat, but it took me 
to highlight issues because no else was.  Why did it even have get to 
this level is vexing to me.

a) Murray, an militant SPF opponent, had one purpose to use the 
experiment status of
    SPF/SIDF as a way to take strategic consolidation control of it, 
related to all his
    work, like with DMARC.  Never mind the questionable justification 
the IETF
    may allow one to take control of a RFC they were not the prime 
author, but do so
    without seeking permission or views from they original editors. 
So right here
    it got off the wrong foot.

b) The charter does state no more work is recommended and I don't know 
where that
    come from because there were clear interest in SPF/SIDF conflict 
corrections.
    The known concerns and any suggestion to seek corrections was not 
open and there
    interests in the practical reality spf/sidf integration existed. 
I understand
    in SPFBIS only focus, but not at the expense of ending SIDF with 
no real
    engineering review to justify it.

c) The charter does reference a draft 4408bis, where it states:

    The success or failure of the Sender ID portion of this IESG 
experiment
    should be evaluated relative to DKIM.

d) Murray did have in a prior report draft a section 2.0 or 3.0 that 
pretty
    much repeated (c) and the need to consider DKIM over SIDF and I 
asked that
    this section be removed.  It was.  Reassure it was no due to my 
input but
    most likely John Leslie to remove the section. I only guessing it 
was Leslie
    because of a side bet with him the "replace SIDF with DKIM" will 
continue to
    be pushed by Murray despite all repeated "Out of Scope" comments 
the report
    had no business to inject.

e) and whenever I wasted more time to provide more reasonable 
arguments and
    empirical information that I guess he could not ignore, he 
repeated in
    in three messages that new input, including new results from new 
scanning of
    data related to SIDF/SUBMIT he stated he was doing, that it 
wouldn't matter
    anyway because it won't change his initial recommendation to 
recommend SIDF
    be made obsolete.

    So why even bother doing a new scan on "millions of domains".

See ya Barry.

Barry Leiba wrote:
> ------------------------------------------------------------------------
>

---

From: S Moonesamy <[email-masked]>
Date: Sun, 22 Apr 2012 13:15:34 -0700

>(offlist)

The SPFBIS mailing list archive might disagree about that. :-)

A document editor documents working group consensus.  The person is 
free to have his/her own opinion and express his/her opinion during 
working group discussions.  What matters is that the document that 
comes out of this working group represents the consensus of this working group.

>    The success or failure of the Sender ID portion of this IESG experiment

I read the SPFBIS charter again before writing this message.  I do 
not see any mention of DKIM in the charter.

>d) Murray did have in a prior report draft a section 2.0 or 3.0 that pretty
>    much repeated (c) and the need to consider DKIM over SIDF and I asked that
>    this section be removed.  It was.  Reassure it was no due to my input but

It's not because the input is not part of a long thread that it was 
not taken into consideration.  Murray Kucherawy, as document editor 
for draft-ietf-spfbis-experiment-05 must have taken that into account 
when documenting the consensus.

>  e) and whenever I wasted more time to provide more reasonable arguments and

There will be a working group Last Call for 
draft-ietf-spfbis-experiment.  It should last around two 
weeks.  There will also be an IETF Last Call which should last two 
weeks.  That's a month altogether.

I made a note about the message posted at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01287.html

This working group has made significant progress on its first 
deliverable due to the efforts of each and everyone.  Let's not forget that.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Apr 2012 17:45:19 -0400

Folks,

Obviously, the intent was a private communication with Barry.  I wish 
to apologize to all, especially Murray.  While we do have conflicts, I 
honestly admire his dedication and work effort within the IETF. I hope 
we can resolve our differences.   For the record, I was open to 
dealing with the SIDF issue and possibly replace it with some 
SPF/DKIM/ADSP/ATPS combined manner since after all, we have 
implemented SPF, PRA/SUBMITTER, DKIM, ADSP, ATPS and VBR and 
streamlining all this is a high interest.  So I was not against the 
consideration if it could be done without negative repercussions.  I 
simply didn't believe the "usage" angle was the correct approach to 
justify the idea, it is a more complex issue.

Sincerely,

-- 
Hector Santos

Hector Santos wrote:
> simply wrong from many angles I don't wish to repeat, but it took me to 
> highlight issues because no else was.  Why did it even have get to this 
> level is vexing to me.