"Meng" == Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
writes:
Meng> Sender ID as currently specified doesn't do that.
Meng> If people want the MAIL FROM to play a role in Sender ID,
Meng> they should say so. If they do not say so, the working
Meng> assumption is that nobody cares.
Well, FWIW I intend to continue to publish SPFv1 records along side
Sender ID records for my personal domain, and will probably do
likewise with my employer's domains when I start publishing records
for them.
If people don't wish to check the MAIL FROM (eg because there is mail
forwarded into their domain through forwarders which are Sender ID
compliant but not SRS-compliant, or just because they don't like
SPFv1) then that's their choice. But I no reason to stop publishing
the information necessary to allow MAIL FROM checks on my domains by
those who wish to perform them.
Meng> I personally think that if the PRA lookup returns "none" or
Meng> "unknown", MAIL FROM should be checked, and if that test
Meng> returns "fail" then the message should be rejected.
Well, if you're only going to check the MAIL FROM when the PRA check returns
has no Sender ID record, then that means I'll still have to continue
publishing SPFv1 records if I want to tell the world that *all* mail
with an envelope sender in my domain originates from one of my MTAs.
Meng> This is in line with the "unified SPF" model.
Personally I think we should leave this as "for future study". I can
live with Sender ID in its current form, and reopening the 'identity'
can of worms at this late stage will just delay Sender ID.
Let's get Sender ID out the door, and then we can think about
validating other identities. It would be relatively easy to add other
identities to Sender ID in a backward-compatible way at a later date,
particularly given the new versioning mechanism.
-roy