In <200505080136(_dot_)49668(_dot_)bulk(_at_)mehnle(_dot_)net> Julian Mehnle
<bulk(_at_)mehnle(_dot_)net> writes:
Scott Kitterman wrote:
I have stayed away from marking mail from shared MTAs that don't prevent
cross customer forgery with PASS. I have also advised others to do that
too. If Meng's new philosophy is right (see excerpt from the last
council meeting below), then those of us on shared MTAs are in trouble.
I agree. In effect, Meng is suggesting that we eliminate "Fail" and
"SoftFail"(?) and, via reputation systems, give "None" and "Neutral"
the semantics of "Fail" and "SoftFail" with somewhat misleading names.
However, I think Meng was just talking about what could have been and
was not seriously suggesting that we change SPF now.
This doesn't directly require a change in the spec, but a statement of
policy (and an update to the web site when such things are being done
again) would likely be enough. The most I would suggest would be a
sentence added to 10.1, perhaps:
"Additionally, it is possible that a malicious sender is an authorized
user for the MTA in question, but not authorized to send for by the
domain owner."
A good idea. Perhaps it would be more appropriate in section 9.4, though.
Wayne, what do you think?
I think this point has some merit. Again, like MarkL, I don't want to
turn the SPF spec into a HowTo document. However, I think the
problems with shared hosts is a technical consideration that we should
mention. Besides something in Implications: Mail Services (Section
9.4), I could also see it being mentioned in the Security
Considerations instead.
I have added a sentence to the end of the second paragraph of section
9.4. Along with other corrections, it now reads:
9.4 Mail Services
Service providers that offer mail services to third party domains,
such as sending of bulk mail, may have to adjust their setup in light
of the authorization check described in this document. If the "MAIL
FROM" identity used for such e-mail uses the domain of the service
provider, then the provider needs only to ensure that their sending
host is authorized by their own SPF record, if any.
If the "MAIL FROM" identity does not use the mail service provider's
domain, then extra care must be taken. The SPF record format has
several options for the third party domain to authorize the service
provider's MTAs to send mail on its behalf. For mail service
providers, such as ISPs, that have a wide variety of customers using
the same MTA, steps should be taken to prevent cross-customer
forgery, such as the use of SMTP AUTH [RFC2554].
Comments?
-wayne