On Wed, 2004-08-18 at 15:30, Harry Katz wrote:
To address the forged Sender/Resent problem I suggest we could add the
following logic:
If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject
a message after DATA.
These terms are odd as the Sender-ID check is called Check_Host() and
not SPFCheck(PRA). From this terminology, it seems there is an
expectation that a different data-set will now exclude the PRA. The
flawed concept behind using Resent-From was to allow the From to be
ignored, as this From domain will not pass! You are suggesting that if
the forwarding domain does not publish, reject the message? Publish or
die.
In other words, if we validate an identity different from 2822.From,
then there's a higher bar for a message to be accepted. The higher bar
is that check of the SPF record must return PASS, else the receiver MAY
reject the message.
This will immediately reject valid mail. You may note the MPR draft
allowed this treatment to be specifically defined.
Another approach that's been discussed is to fall back to doing a check
on the MAIL FROM address when there is no SPF record for the PRA.
Both alternatives share some things in common:
- Neither approach permits rejecting a message before DATA, unless
SUBMITTER is present. If SUBMITTER is present then both approaches
permit rejection before DATA.
This is not true for the MPR draft. : )
- Both place a higher burden on the "specialty" senders, namely the
forwarders and list servers. This is a good thing. (Not that it's a
good thing to place a burden, but that the burden is on the specialty
senders rather than all MTAs in general.)
Again, the MPR draft does not place a higher burden upon these MTAs. It
does however allow institutions to ensure their mail is not valid when
the From does not indicate coming from their Mail Channel regardless of
whether the Resent-From was published by some entity. The MPR provides
a suitable treatment for this class of mail, without breaking other
mail. Remember, forwarded mail is still rejected.
- Neither approach can be done on day 1. At minimum we need to allow
time for the specialty senders to publish SPF records.
The MPR scheme would not need to impose any changes for institutions to
have restrictions placed upon their From mailbox.
I think the approach I'm suggesting has several advantages:
- It's semantically cleaner. We're basing the check on 2822 identities,
with a higher burden in special cases where PRA is different from
2822.From. This isn't just a theoretical distinction. As we have
repeatedly discussed on this list there are substantial semantic
differences between MAIL FROM and the 2822 identities.
This Resent-From may evolve into being the normal PRA. In which case,
simply authenticating the EHLO domain and making this visible would
arrive at that point much sooner, and not by imposing sets of "burdens"
for mail to be accepted. It would also more quickly educate users and
not run afoul of PRA selection errors or IPR contracts. : )
- More importantly, this allow us to give much clearer directions to
senders in terms of what to publish. You publish the IP addresses of
servers authorized to send mail on behalf of your domain. We're not
trying to mix this up with the IP addresses of servers that receive
bounce messages on behalf of your domain.
You just suggested a MAIL FROM fall-back mode?
- This approach involves fewer DNS lookups because you're only
performing the spoof check on one identity in all cases.
You have simply decided more otherwise valid mail should be rejected.
Thus, if a spammer wants to forge a Sender or Resent- header, they have
to use their own domain name. That'll get block-listed fairly quickly. I
belive that plugs the hole that we're addressing.
You seemed to have overlooked the "open" list problem. The spammer can
use other people's records. You will be black-listing these people that
have done nothing wrong, other than implemented this specification and
made the mistake of publishing a record. Publish and die.
At this late point in the process I'm not sure whether this idea needs
to go into the spec itself. It could be written up in a BCP.
Now you think the best practices should be to reject mail, if these
records are not found? Publish or die.
Death seems inevitable. : )
-Doug