[spfbis] Interop Report needs two data points related to WG issues

[Hector Santos <[e-mail]>]

Hi,

I don't know if this is possible to gather, but there two issues on 
the WG table that perhaps having some usage data would help in the 
writing of 4408BIS spec.

I have an real example below showing both issues, but first my action 
proposals:

                                =================================
(1) For the Interop-report, if practically possible:

The relates to Received-SPF and the issue #12 proposal to replace it 
with the proposed standard Authentication-Result header.  IMO, this 
item will be highly debated item, and probably if the consideration is 
deemed worthy to pursue, the debate will mostly be about in how it is 
worded with the   ideal preference to accelerate deployment with a 
replacement worded as opposed to the more relaxed deprecation wording. 
  I am wondering if having some usage data is relevant for the interop 
report to help implementators decide with any deprecation or 
replacement 44084BIS outcome.

Proposal:

Collect and report any data on the usage of Received-SPF header. 
Collect and report any data on the current usage of the 
5322.Authentication-Result header to report SPF or Sender-ID results.

Collect and report data on how deployed SMTP receivers have applied 
SPF policy violations for domains using hard fail (-ALL) SPF policies. 
  I think it is correct to suggest that ultimately a local site SPF 
deployment can operate in two ways for -ALL policy violations:

      - REJECT-ON-FAIL
      - MARK-ON-FAIL

It would good to know how SPF deployment for one of the other method. 
  There are good reasons for both and also bad reasons both.  But only 
one has a higher coverage to protect users, and in my view, whatever 
mode is used, the end result as far as the user is concern should be 
same or nearly the same.

If one mode means (REJECT) is selected because the mail is considered 
bad, then opting to mark it instead should, in my engineering design 
view, offer the same negative rejection quality allowed the user to 
leverage and decide.  In other words, marking a message should not 
offer any new possible value about the message if an alternative mode 
of acting on the message is direct rejection.

Example below illustrates this.

2) New issue to track

This is related to a recent discussion on what 4408 says or doesn't 
say regarding REJECT-ON-FAIL and the different viewpoints that was in 
the past and appear to be rearing its head again, a source of conflict.

It is specifically written "Mark It or Reject" for a SPF domain policy 
resulting a FAIL (-all). I think the reject option is well defined but 
not "Mark it."

Proposal:

Define what "MARK-ON-FAIL" means.

Does this just mean to use the SPFBIS recommended reporting header, 
currently Received-SPF? or have additional meaning like stream 
classification, i.e. quarantine to a Junk/Spam Email" user 
storage/folder?  How does a specific type of MUA relate to this, i.e. 
Online vs Offline MUA access where with Online, the backend has better 
controls and with offline it is limited to the Offline MUA capabilities?

                                =================================

Real Example showing that touch base with the above issues.  This 
example usages hotmail.com and I sincerely want to express that none 
of this should misconstrued as negative on any individual, hotmail.com 
or questions their methodologies.   My purpose is to hopefully show 
areas that relate to important SPFBIS considerations.

This all started with a 2005 R&D effort to see two things and also 
confirm a third using the large ESP at the time, it included 
hotmail.com, aol.com, yahoo.com, earthlink.com and msn.com, etc.

    - Are the still working as long traditional ESPs not enforcing 
RFCx822 at DATA?
    - Which means are supporting SPF?
    - Are they always accepting and perhaps discarding illegal mail?

I have a 2005 recorded hotmail.com session that showed an illegal MAIL 
FROM showed it did not reject it based on SPF/SIDF. The DATA payload 
that only had single line "Hello No Headers" (no headers) was still 
working as a traditional host and not enforcing RFCx2822.  The message 
was accepted, unfortunately for this June 2005 test, I don't recall if 
I tried to confirm it appeared in my hotmail.com inbox or it was 
discarded.

Related, I strongly recollect the Hotmail.com announcement that they 
were going to begin to enforce RFC2822 and wondered how this can 
change the industry because this as not something typically enforced 
for large suite of application reasons where the RFC822/2822 headers 
were simply not required to accept the message.

So I tried it again today, in 2012, asking the same 2005 questions. 
The following is a capture telnet port 25 session:

           ---- Captured hotmail.com SMTP session ---------

220 SNT0-MC3-F37.Snt0.hotmail.com Sending unsolicited commercial or 
bulk e-mail
     to Microsoft's computer network is prohibited. Other restrictions 
are
     found at http://privacy.microsoft.com/en-us/anti-spam.mspx.
     Sun, 22 Apr 2012 01:45:46 -0700
HELO hdev2
250 SNT0-MC3-F37.Snt0.hotmail.com (3.15.0.97) Hello [208.247.131.22]
MAIL FROM: <[e-mail]>
250 [e-mail]....Sender OK
RCPT TO: <[e-mail]>
250 [e-mail]
DATA
354 Start mail input; end with <CRLF>.<CRLF>
expecting rejection
.
250 <[e-mail]> Queued 
mail for delivery
QUIT
221 SNT0-MC3-F37.Snt0.hotmail.com Service closing transmission channel
               ------------------------------------------

Please note the intentional usage of the altavista.com domain with SPF 
policy of -ALL, and no headers were used for data as was done in 2005.

I also checked my Windows Live MUA and it showed the message was 
delivered, however, the backend put it into the "Junk E-Mail" folder. 
  The delivered email has the following MUA message source view:

           ---- Message source view of delivered email ---------

Authentication-Results: hotmail.com;
  sender-id=temperror (sender IP is 208.247.131.22) 
header.from=[e-mail];
  dkim=none header.d=altavista.com; x-hmca=none
X-SID-PRA: [e-mail]
X-DKIM-Result: None
X-Message-Status: n:0:n
X-SID-Result: TempError
X-AUTH-Result: NONE
X-Message-Delivery: Vj0xLjE7dXM9MDtsPTA7YT0wO0Q9MjtHRD0yO1NDTD02
X-Message-Info: 11chDOWqoTmjqhOzvWWho/vK8oL2x1FIoE........===
Received: from hdev2 ([208.247.131.22]) by 
SNT0-MC3-F37.Snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4900);
      Sun, 22 Apr 2012 01:46:04 -0700
From: [e-mail]
Bcc:
Return-Path: [e-mail]
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 22 Apr 2012 08:46:10.0973 (UTC) 
FILETIME=[5E03ACD0:01CD2064]
Date: 22 Apr 2012 01:46:10 -0700

expecting rejection
               ------------------------------------------

There are many points that be stated, logistic questions, but I want 
to just highlight the key issues and questions are;

   - RFC5322 was not enforced.  Not expected IMV.

   - It auto creates new headers and usages RFC5322 which does not 
require the adding
     of the To: header, like others will do with strict RFC822 local 
site policies
     or just to fill it an as separate option usually offered, i.e. 
EnableMissingTo.

   - Does HOTMAIL.COM perform any kind of SMTP level rejection or is 
it an
     always accept farm of inbound servers?

   - If it supports SPFv1.0 at SMTP, this would be example of RFC4408 
option to
     do MARK-ON-FAIL and did not honor the domains strong policy of a 
NO MAIL
     SPD domain policy email practice declaration. In other words, the 
policy has
     to IPs or directives to compare, its a simple -ALL which means NO 
MAIL is expected
     for this domain.

   - But it didn't use a Received-SPF in reporting an SPF result, 
which should of
     showed if it was supported:

         Received-SPF: fail (......)

   - So does it deploy SPF at SMTP?

   - It uses Authentication-Result to report sender-id: temperror. Why 
is this a
     temporary error?


OPTIONAL READING:

If we are going to consider the recommendation to replacing 
Received-SPF with Auth-Res, it need to offer the same functionality in 
terms what the SPF policy says, -ALL means a FAIL was expected. It 
should not be translated into different meanings.   I don't see this 
as big issue, but if anything it would related to the my next view 
regarding the type of MUA expected to be used.

As a vendor with a mail system support for multiple device portals for 
mail access, from dumb terminals, console, ANSI/VT10x UI, to offloaded 
native GUI online MUA, Web UI, to pure offline store and forward MUA 
and also mixed online/offline, it was always a difficult challenge to 
support all this and also single source the basic backend framework as 
far what is secured and what is displayed.

Newer systems has the luxury to stick with the new/current method, 
like web mail only.  Others will offer web, pop3 or imap, and there is 
a trend to go back to the ONLINE MUA only as the only way.  Cases in 
point, Microsoft abandoning NNTP access for LiveID authenticated MSDN 
web forums only and high-value user-vendor transaction are now 
increasing pushed to online online - the smart phone, small device 
evolution I believe is enabling it.

The point is that something the backend assumed only one dominate mode 
of access and when this is the case, it can do things that offer safer 
mode or lower risk to users.  For example, even though the above SMTP 
session with faulty transaction was accepted, it did quarantine it 
into my Junk Email box.

But what if there was a 3rd party MUA, will it work in the same way? 
In the case with Hotmail.com, I was using Windows Live and it used a 
SOAP/HTTP protocol to access the backend mail and it had the logic to 
show the separate sort/split mail folders.  The good news is 
hotmail.com offers pop3 port 995 access and  with my Thunderbird MUA, 
the junk email was not included as part of my normal new mail

So in this case, without confirmation, the backend MARK-ON-FAIL also 
meant a backend classification to separate the the bad from the good 
normal email.  Is this material for SPFBIS 4408BIS to consider in 
defining what MARK-ON-FAIL means?


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