Subject: [spfbis] SUBMITTER survey

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Apr 2012 20:19:49 +0000

For the sake of being thorough, I have initiated a second survey, this time checking MTAs for which ones advertise SUBMITTER.  The 220 banner and whether or not SUBMITTER was among the listed ESMTP extensions will be recorded for each host; the banner is recorded so that we can tell which ones appear to be the same MTA software.  It's checking the MXes of over a million domains, filtering for duplicates.  This will obviously take some time, but it has reasonable timeouts so we should get a decent sample subset in a short period of time.

I don't expect the results of this to allow for a different conclusion than the one we've already reached.  Even if we find a lot of MTAs offering the extension, not many sending domains expect it to be used.  Specifically, by the specs, SUBMITTER provides input to Sender-ID (either in place of, or for direct comparison to, the PRA), and there are so few "spf2.0/pra" policies out there (under 5%) that even if SUBMITTER is offered and used, the value is typically discarded.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 Apr 2012 17:14:27 -0400

> I don't expect the results of this to allow for a different conclusion than the one we've already reached.  Even if we find a lot of MTAs offering the extension, not many sending domains expect it…

Hi,

Ok, but the report should also be prepared to ask and answer the 
question if there is a new lost of email security for 5% of the 
domains when SPFBIS recommends receivers should not longer be 
supported and just ignore it.  What level of Security Threshold does 
the IETF use to measure significant? 1% 5% 10% or higher?  Even if it 
happens for the few, it can also raise product liability concerns - 
its not something I am trained to ignore.

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Apr 2012 17:23:57 -0400

On Friday, April 06, 2012 05:14:27 PM Hector Santos wrote:
> > For the sake of being thorough, I have initiated a second survey, this
> > time checking MTAs for which ones advertise SUBMITTER.  The 220 banner
> > and whether or not SUBMITTER was among the listed ESMTP extensions will
> > be recorded for each host; the banner is recorded so that we can tell
> > which ones appear to be the same MTA software.  It's checking the MXes
> > of over a million domains, filtering for duplicates.  This will
> > obviously take some time, but it has reasonable timeouts so we should
> > get a decent sample subset in a short period of time.
> > 
> > I don't expect the results of this to allow for a different conclusion
> > than the one we've already reached.  Even if we find a lot of MTAs
> > offering the extension, not many sending domains expect it to be used. 
> > Specifically, by the specs, SUBMITTER provides input to Sender-ID
> > (either in place of, or for direct comparison to, the PRA), and there
> > are so few "spf2.0/pra" policies out there (under 5%) that even if
> > SUBMITTER is offered and used, the value is typically discarded.
> Hi,
> 

Support or non-support of SUBMITTER is irrelevant from a security perspective 
unless you are worried about people spoofing resent-sender.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Apr 2012 20:46:15 -0400

My chair hat is on, but I have not discussed this with SM yet.

Hector:

On Fri, Apr 06, 2012 at 05:14:27PM -0400, Hector Santos wrote:

> supported and just ignore it.

Why?  This WG is not chartered to add SUBMITTER support to SPF.  Even
if we concluded that it would be desirable, to do that would require
rechartering.

But in any case, without an operational definition of "email security"
in your note, the claim is inoperative.  The empirical evidence we
have so far is that this feature is just not widely supported.  You
would need a strong argument indeed to show that a feature that is not
widely used and is also not part of the work we are chartered to
undertake is something that we nevertheless need to address.

If you have alternative study evidence to contradict the evidence
Murray has so far produced -- i.e. to show that the feature is in fact
widely used in conjunction with SPF, or else that the feature provides
critical additional benefit not provided by SPF, then present that.
Your note instead attempts to define the conclusions we are drawing
from the data in advance, so as to reflect a preferred outcome.
That's not drawing conclusions from data; that's drawing a conclusion
and then finding data.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 Apr 2012 21:20:14 -0400

> That's not drawing conclusions from data; that's drawing a conclusion

I don't agree that that view of the post.  In fact, what you describe 
is exactly what was being done first. State a goal, then go about to 
find data to justify killing the protocol.

It is a premature report conclusion on the first point that there is 
no support, incorrect on the 2nd point only two MTAs supporting it, 
and irregular on the 3rd point to use a subjective, unproven "Malware" 
quality of message consideration in an inter-op report to explain the 
clear evidence of extremely wide client support and why this 
subjective type of client support just not be considered.

http://www.ietf.org/mail-archive/web/spfbis/current/msg01054.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg01062.html

There is clear evidence of thousands of MTA site support.  It should 
not matter than its just two MTA vendors. This would be suggesting 
sendmail is or is not supporting XYZ feature, therefore it is/not a 
standard, when in fact, it would be vital data point due to its wide 
MTA sites implementation and would be use as evidence of support or 
lack there of.

I also believe it is not my duty to justify why it should remain, but 
I believe I did provide clear interop, engineering and security 
related input. IMO, it is duty of the reporter to clearly justify why 
should it be removed and also make sure there is no repercussions, 
including security related potentials when it is fact removed.

Finally, the WG is chartered to decide its fate.  The goal was pretty 
much well known what was wanted by the editor and in my opinion, the 
reasons cited so far are not quite adequate.

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Apr 2012 00:01:28 -0400

Hi,

I'm an implementator the protocol automaton and 2nd guessing the value 
or source of the PRA is not part of it.  The reasons why SIDF clients 
use it would be expected to be one based on security and/or their the 
ADMD desire to protect the PRA domain. So I don't quite follow the 
presumed irrelevancy of security being made.  If there is a 5% usage 
of SPF2.0/PRA, subjectively dropping the protocol where there is clear 
protocol support for it, needs to satisfy answering the ADMD lost of 
PRA security question.  It can't be ignored or thrown side lightly.

---

From: Dotzero <[email-masked]>
Date: Sat, 7 Apr 2012 04:21:28 -0400

On Sat, Apr 7, 2012 at 12:01 AM, Hector Santos <[email-masked]> wrote:
>> Support or non-support of SUBMITTER is irrelevant from a security
>> perspective unless you are worried about people spoofing resent-sender.
>
>
> Hi,
>
> I'm an implementator the protocol automaton and 2nd guessing the value or
> source of the PRA is not part of it.  The reasons why SIDF clients use it
> would be expected to be one based on security and/or their the ADMD desire
> to protect the PRA domain. So I don't quite follow the presumed irrelevancy
> of security being made.  If there is a 5% usage of SPF2.0/PRA, subjectively
> dropping the protocol where there is clear protocol support for it, needs to
> satisfy answering the ADMD lost of PRA security question.  It can't be
> ignored or thrown side lightly.
>
>

Hector,

Apart from the fact that we are updating 4408 and not SIDF, PRA is
broken (I can send mail all day long and get a neutral no matter what
a domain publishes) which I publicly documented as far back as 2006.

Mike

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Apr 2012 08:58:26 -0400

Andrew Sullivan wrote:

> in your note, the claim is inoperative.  

Andrew,

In regards to SPF, I submit it is an email security-related protocol 
and thus prime reason SPF/SIDF has enjoyed wide adoption and 
deployment. It wasn't done just for kicks and laughs. The abstract is 
pretty clear what SPF attempts to offer an email domain protection and 
security protocol:

    E-Mail on the Internet can be forged in a number of ways.  In
    particular, existing protocols place no restriction on what a sending
    host can use as the reverse-path of a message or the domain given on
    the SMTP HELO/EHLO commands.  This document describes version 1 of
    the Sender Policy Framework (SPF) protocol, whereby a domain may
    explicitly authorize the hosts that are allowed to use its domain
    name, and a receiving host may check such authorization.

Any suggestion the SPF/SIDF protocols are not email security-related 
protocols is "inoperative."

---

From: S Moonesamy <[email-masked]>
Date: Sat, 07 Apr 2012 09:12:23 -0700

After reading the messages on this thread, it seems that the 
discussion is about the following text in draft-ietf-spfbis-experiment-00:

  (i) "In a survey of numerous MTAs in current or recent use, only two
      (Santronics WinServer and McAfee MxLogic) were found to contain
       implementations of the SMTP SUBMITTER extension as part of the MTA
       service, which could act as an enabler to Sender-ID."

I gather that there isn't any disagreement about Santronics WinServer 
and McAfee MxLogic having implementations of RFC 4405.

Are there any other SMTP server implementations of RFC 4405, and if 
so, please provide information which can be used to convince the IETF 
about that fact?

And this text:

   (ii) "An unknown number of clients implement it; although there is 
substantial
         activity showing its use in logs, it is unclear whether these are
         separate implementations"

The above mentions "an unknown number of clients implement it".  Are 
there any other (excluding the names mentioned above) SMTP client 
implementations of RFC 4405?

And this text:

   (iii) "by legitimate senders, or merely instances of distributed automated
          malware seeking to improve their odds of reaching the end user."

Is the issue about part (i), part (ii), part (iii) or something else?

Regards,
S. Moonesamy
SPFBIS co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 Apr 2012 04:47:06 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Saturday, April 07, 2012 9:12 AM
> To: [email-masked]
> Cc: Andrew Sullivan
> Subject: Re: [spfbis] SUBMITTER survey
> 
> After reading the messages on this thread, it seems that the discussion
> is about the following text in draft-ietf-spfbis-experiment-00:
> 
> Are there any other SMTP server implementations of RFC 4405, and if so,
> please provide information which can be used to convince the IETF about
> that fact?

To give background on the cited text:

I found no others after doing searches online for any documentation or discussion of other implementations.  I only found out that MxLogic does it from a MAAWG mailing list and WinServer from this list.

Three links to other instances of "submitter" were posted to the list earlier, but they were red herrings: One used "submitter" to talk about the SMTP AUTH identity, one used it to refer to a component of a mass mail system that basically acted as an MSA, and one was a software module for submitting homework (i.e., it was courseware, and had nothing at all to do with email).  Thus, they aren't considered for the experiment report.

The survey being run right now has so far polled 19,553 distinct MTAs (of the million-plus domains it will check, it's going in alphabetical order and has only gone as far as "ag*" at the moment).  774 of those claim SUBMITTER as an extension.  That's less than 4%.

That survey records the MX name that was queried in each instance.  Of the 774 that advertised SUBMITTER, all but 39 were actually MxLogic.  The bulk of the remainder were mx-route.com, which I presume to be something like what MxLogic does.  The rest appeared to be unassociated instances of something called "mxl_mta".

> And this text:
> 
>    (ii) "An unknown number of clients implement it; although there is substantial

Actually I didn't find documentation or discussion of a single client implementation that uses it; MxLogic and WinServer are SMTP servers that use it.  The text you cited above is based on Hector's logs that show clients actually using it, so we know they exist.  However, unlike SMTP servers, SMTP clients don't identify themselves in any interesting ways, so we can't tell from his logs whether all of them are the same implementation, or all of them are unique implementations, or somewhere in between.

>           malware seeking to improve their odds of reaching the end user."

A quick glance over the log Hector provided certainly looked to me a lot like the SUBMITTER parameter was generated rather than being legitimate most of the time, a lot like what spam bots and other malware do for MAIL FROM.  That made me think that these are mostly spam bots using SUBMITTER as an attempt to do anything to improve their chances of getting to the inbox.
 
I admit that last clause is an educated guess at who, in general, those clients are.  We could remove it if we believe it's a problem, as I suspect it doesn't affect the rest of the document, but I thought it might be of interest to readers.

To the point raised about a small number of implementations but a wide net, I agree that we need our analysis to consider both breadth and depth of implementation (i.e., number of implementations vs. deployment of each), but I also think we are doing that already.

But even if Exchange, sendmail and postfix all had implemented SUBMITTER, there's no ignoring the fact that such a small segment of the ecosystem is actually asking for PRA processing which is where SUBMITTER is actually used.

-MSK

---

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

S Moonesamy wrote:
> [SEE http://www.ietf.org/mail-archive/web/spfbis/current/msg01078.html]
> 

Yes, Yes, Yes and Yes.

Short comment and suggestion.

I think the WG should get a better handle of the issue and address the 
fundamental conflict that existed since day one which started the need 
for an IETF MARID concluding experiment:

     The CEP (CallerID Email Policy) XML version of SPF introduction 
of the
     payload based 3rd domain identity called the PRA.

I propose we stop this slippery slope "Who's Who Usage" measurement 
and focus on the technical merits of RFC4407 (PRA) as part of the 
integrated SPF protocol solution to deal with all the transactional 
domains that may be part of an IP::DOMAIN SPF1.0 vs SPF2.0  domain 
protection policy.

If the SPFBIS group consensus concludes the PRA was technical failure 
and offered little value to the total integrated SPF framework, the 
concluding to abandoning it, automatically defines the result of 
SenderID and SUBMITTER.

<OPTIONAL>

Optional reading and background:

My opinion.

One of the main difficulties with this issue is that there are 
different viewpoints of the SPF Experiment goals and the SPFBIS key 
cogs charter authoring and goals to "End" the experiment.  It was in 
conflict and error with the integrated deployment of two similar 
protocols that only differ with one essential idea:

       The CEP (CallerID Email Policy) XML version of SPF introduction 
of the
       payload based 3rd domain identity called the PRA.

When CEP was changed to SenderID and the agreement was to allow it to 
piggy back of the SPF established policy language syntax, including 
using a XML structure, at the end of the day, the so called 
"Experiment" was over how two protocols would work together to cover 
three potential domains to authorized an email sender:

   - SPF1.0
      IP::EHLO/HELO domain (ENVELOPE)
      IP::MAIL FROM domain (ENVELOPE)
   - SPF2.0
      IP::PRA (PAYLOAD)

While I personally had an opinion for the algorithm used to extract 
the PRA, its need to be supported was not in question, especially one 
of the top Software company was purposing it was part of the total 
email use case scenarios and the FTC was very interesting in making it 
happen for wide adoption.  The reason concern was the implementation 
overhead and hence the RFC4405 SUBMITTER was invented to help address 
that PRA overhead concern.

Now I am being told to believe a SPFBIS effort and interop report that 
for all intent and purposes implies the PRA was a failure and 
therefore we are ending SIDF and all receivers can being to drop the 
support of the SUBMITTER protocol without any repercussions.

But its not saying the PRA was a failure. Instead its concluding 
SUBMITTER is not supported by a majority of MTA out of the box, and 
when it is supported by the few MTA vendors but in fact enabled by 
thousands of MTA sites, the high volume of SUBMITTER MTA clients using 
this MAIL FROM parameter should be ignored as possibly a high volume 
of "Malware" or wrong type of PRA clients exposing it via SUBMITTER.

I just think this is not correct and its considerate of the many 
engineering considerations that was put all leading up to the 
conclusion of the past WG and the initiation of multi-protocol 
integrated SPF framework and IETF experiment.
</OPTIONAL>

---

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

Hi,

I don't know where to begin but I think the effort is not correct from 
many angles.  But I do believe we can remedy the situation with a 
valid WG review of whether part of the 2006 IETF experiment question 
regarding the PRA is something the SPFBIS can finally decide on.

Its a waste of time trying to justify lack of usage and hope on 
leveraging the "IETF consensus" to ram down a predetermine goal. The 
report is not providing convincing reasons why SUBMITTER should be 
dropped and no longer supported by receivers.

I think the "experiment" conclusion regarding SIDF needs to be based 
on the value of the RFC4407 (PRA).

If the WG believes this part of the consolidated SPF consolidations is 
no longer important from an email security-based use case standpoint 
as proposed by Microsoft, then that would automatically put an end to 
4405, 4406 and 4407.

However, if the WG is not ready to make that decision, then in my 
view, the WG should not be making any determination on these protocols 
based on usage.   It should just focus on 4408 and no more, making no 
INTEROP report on 4405, 4406 and 4407.

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

---

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

Hector,

On Tue, Apr 10, 2012 at 05:11:32AM -0400, Hector Santos wrote:
> view, the WG should not be making any determination on these
> protocols based on usage.   It should just focus on 4408 and no
> more, making no INTEROP report on 4405, 4406 and 4407.

Speaking as co-chair, your view is noted.  Thank you for making it
abundantly clear.

Best regards,

Andrew 

-- 
Andrew Sullivan
[email-masked]