I hope my input is considered 'reasonable' I just don't see the true
usefulness of the submitter extension yet. SPF can solve all the three
examples provided in the SUBMITTER proposal using a simple modification to
the SPF lookup provisions by adding the "chain of trust" concept to it:
Lets go thru each example which attempt to illustrate real basic mail
forwarding problems that "SPF classic" currently suffers with. I hope to
show that SUBMITTER offers no value or benefit against the major change
requirements and show how a SPF can accomplish the same functionality
SUBMITTER attempts to address.
5.2 Mail Forwarding:
This problem has two separate MARID authentication concepts:
Example:
S: 220 alumni.almamater.edu ESMTP server ready
C: HELO example.com
S: 250 alumni.almamater.edu
C: MAIL FROM:<alice(_at_)example(_dot_)com>
S: 250 <alice(_at_)example(_dot_)com> sender ok
C: RCPT TO:<bob(_at_)alumni(_dot_)almamater(_dot_)edu>
Using SPF:
SPF(MAILFROM,IP) --> PASS
This must be true in order to accept the final destination message,
including to allowing the final result to be true as well.
In this example, the final destination has a user defined mail forwarding
address which the MDA turns around and sents it out:
S: 220 woodgrove.example.com ESMTP server ready
C: HELO alumni.almamater.edu
S: 250 woodgrove.example.com
C: MAIL FROM:<alice(_at_)example(_dot_)com>
S: 250 <alice(_at_)example(_dot_)com> sender ok
C: RCPT TO:<bob(_at_)woodgrove(_dot_)example(_dot_)com>
S: 250 <bob(_at_)woodgrove(_dot_)example(_dot_)com> recipient ok
The classic SPF issue result will be::
SPF(MAILFROM, IP) ---> FAIL
or some non-pass SPF result because the IP no longer matches.
However, this is solved using a SPF/MARID HELO provision to validate the the
MARID compliant alumni.almamater.edu domain.
Using SPF:
SPF(MAILFROM, IP) => FAIL
SPF(HELO, IP) => PASS
This concept is fundamental to the chain of trust concept. It is impossible
to have a valid overall SPF result with a failured SPF HELO result. It
implies that the original receiver is NOT SPF compliant!
5.3 Mobil User
The same issue applies here with this mobil user as well. Using a SPF/MARID
HELO provision to validate the the MARID compliant consolidatedmessenger.net
domain is all that is required.
Example:
IP address of consolidatedmessenger.net MTA
S: 220 alumni.almamater.edu ESMTP server ready
C: HELO consolidatedmessenger.net
C: MAIL FROM:<alice(_at_)example(_dot_)com>
S: 250 <alice(_at_)example(_dot_)com> sender ok
C: RCPT TO:<bob(_at_)alumni(_dot_)almamater(_dot_)edu>
S: 250 <bob(_at_)alumni(_dot_)almamater(_dot_)edu> recipient ok
Using SPF:
SPF(MAILFROM, IP) => FAIL
SPF(HELO, IP) => PASS
Again, this concept is fundamental to the chain of trust concept. It is
impossible to have a valid overall SPF result with a failured SPF HELO
result.
5.4 Guest E-mail Service
Finally, the same applies here as well.
Example:
IP address of email.exemplarhotel.com MTA
S: 220 alumni.almamater.edu ESMTP server ready
C: HELO email.exemplarhotel.com
S: 250 alumni.almamater.edu
C: MAIL FROM:<alice(_at_)example(_dot_)com>
S: 250 <alice(_at_)example(_dot_)com> sender ok
C: RCPT TO:<bob(_at_)alumni(_dot_)almamater(_dot_)edu>
S: 250 <bob(_at_)alumni(_dot_)almamater(_dot_)edu> recipient ok
Using SPF:
SPF(MAILFROM, IP) => FAIL
SPF(HELO, IP) => PASS
Again, this concept is fundamental to the chain of trust concept. It is
impossible to have a valid overall SPF result with a failured SPF HELO
result.
In summary, I see no benefit to SUBMITTER. It has a high degree of SMTP
change requires with no add-valued over what a simple modification to the
SPF functional provisions on HELO lookup logic by including the concept of
chain of trust. It provides the same result at the 2821 level with maximum
capability (no SMTP change).
I hope to be proven wrong with this because implementing submitter is going
to be a major redesign cost with little guarantee of effectiveness and
usefulness.
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com