Subject: [spfbis] FW: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 19:26:54 +0000

This version is significant because it includes a first run at the conclusions section, and the survey data presented are more complete.

Note that the conclusions are ONLY an initial proposal.  I don't claim they have working group consensus at this point; it's just a starting point for discussion.  We are still waiting for the Hotmail data to come in, plus any other data people might want to submit before we finalize the document.

However, if you have any changes you want to see to the conclusions, I suggest it will be important to justify your statements against the data we have, or provide new data.  Opinions and theories are less useful than facts here, since we're basing all of this on observation and not on speculation.

With that said, have at it!

-MSK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2012 12:22 PM
To: Murray S. Kucherawy; [email-masked]; [email-masked]
Subject: New Version Notification - draft-kucherawy-spfbis-experiment-04.txt

New version (-04) has been submitted for draft-kucherawy-spfbis-experiment-04.txt:
http://www.ietf.org/internet-drafts/draft-kucherawy-spfbis-experiment-04.txt

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-kucherawy-spfbis-experiment-04

IETF Secretariat.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 19:53:58 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, April 04, 2012 12:27 PM
> To: [email-masked]
> Subject: [spfbis] FW: New Version Notification - draft-kucherawy- spfbis-experiment-04.txt
> 
> This version is significant because it includes a first run at the
> conclusions section, and the survey data presented are more complete.

I should also add that there's an appendix now that talks about the type 99 experience.  I think this is important given all the chatter elsewhere in the IETF lately about developing protocols that use the DNS to store stuff.  If I got any of the history in there wrong, please do feel free to provide alternate text that sets the story straight.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 04 Apr 2012 20:04:17 -0400

Hi,

With a quick review, I believe the recommendation #4 regarding 
SIDF/SUBMITTER/PRA is premature.  This is a clear case of a HMM 
(Hidden Markov Model) [1] where an analysis is done with one outcome 
can have a completely different take just by enabling an server option.

IMTO, the key questions to be investigated:

     Why is there a significant amount of clients using SUBMITTER once the
     server enabled the option?

     If recommendation #4 is conclusive, is there an new error based in
     the reflection the server deems as appropriate for SPF 
verification, and it
     would open a window of possible non-protected transactions by 
clients using
     the PRA?

It is very easy to look at various servers "directly" and conclude 
there are enough ESMTP servers enabling SUBMITTER extension, but then 
again this form of analysis can apply to many SMTP extensions we have 
deemed as worthy standards yet are not very popular at the server 
level across the board. On the flip side, even where there are 
significant server support for one or more many extensions, it doesn't 
mean clients need to support it.  Would that suggest the protocol 
should be made obsolete due to lack of client support?  Of course not, 
and if that was the modus operandi for support, quite a few ESMTP 
protocols would fail to exist today.

So in my view, the SPFBIS experiment report needs to look at reasons 
why there are clients who have obviously took the coding time and 
expense to programmatically extract the PRA, programmatically modify 
their ESMTP client to look for the ESMTP service SUBMITTER keyword and 
then programmatically add SUBMITTER= to the 5321.MAIL FROM command. 
All of which does not suggest an easy and no cost endeavor. It took 
"Engineering Thinking" to go about this SUBMITTER consideration by the 
clients.

At best, the recommendation made is that SERVERS are not supporting 
it, but can't match with what appears to be a high client technical 
desire to support it.   When we look at servers, such as Microsoft 
Exchange, having ESMTP support for SUBMITTER may be an provisional or 
3rd party vendor support [2][3][4] implementation.

Overall, IMO, until questions such as the above are addressed, 
recommendation #4 is premature and its certainly one resembling a 
Hidden Markov Model.

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

[1] http://en.wikipedia.org/wiki/Hidden_Markov_model
[2] http://www.bluej.org/extensions/submitter/submitter.html
[3] http://www.equisys.com/technotes/ztn1418.htm
[4] 
http://stackoverflow.com/questions/5639836/problem-sending-mail-with-javamail

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

---

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

Hi,

I have more data and two comments regarding this section 3 paragraph:

    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.  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 by legitimate senders, or merely instances
    of distributed automated malware seeking to improve their odds of
    reaching the end user.

First, in regards to the last sentence, IMO, I don't think this report 
should be dealing with unproven subjective quality of message or 
legitimate usage considerations and use this basis for experiment 
conclusions.

Yes, there are brownie points, but that applies to ALL anonymous email 
senders - good or bad because we (IETF by developing these protocols) 
told them to support it since it will benefit everyone else to get on 
board.  The DMA even recommends a BCP for compliant eMarketing Mail 
Delivery Practices.  More importantly, clients using SUBMITTER is not 
a zero-cost implementation.  Code changes are required to detect the 
ESMTP SUBMITTER service keyword, code changes are needed to parse the 
RFC5322 to extract the PRA and code changes are necessary to add the 
SUBMITTER=pra attribute to the MAIL FROM command.

I am proposing this sentence be removed from the paragraph,

Second, in regards to the initial part of the paragraph, the term MTA 
should be clarified. Was the survey a look at "MTA Vendors/Software" 
or "MTA Sites?"

The two cited MTA are vendors. I did a quick look of our support site 
outbound mail SMTP session log this morning and the following domains 
all have SUBMITTER enabled.

     pcpursuits.com
     bozax.com
     cisbbs.nl
     box24.ch
     foxriver.net
     superp.com
     Gsd-Co.Com
     thirdrockbbs.com
     reu.org
     icsbbs.com
     tbsp.com
     rdfig.net
     techware.dynip.com
     opcug.ca
     foxriver.net
     newsserviceflorida.com
     statehousenews.com

and that is just with small technical support group mailing list. Our 
much larger general announcement/newsletter mailing list will show 
perhaps 4-5 hundred domains using SUBMITTER.  Sure, small potatoes, 
but its not just two and McAfee, a much larger vendor, probably has a 
larger customer base of SMTP servers with SUBMITTER server support.

Does this change anything regarding the perception SUBMITTER is not 
supported?