Subject: RE: TECH OMISSION: Stronger checks against email forgery

From: "Jim Lyon" <[email-masked]>
Date: Fri, 27 Aug 2004 14:22:02 -0700

On Thursday, August 26, 2004 at 3:01 PM, Doug Otis argues: (via my
summary / paraphrase)

> That spammers will create messages that forge domains whose SenderId
records include "+all".
Yes, they will.  And those domains will get a (richly deserved) bad
reputation, and most people will refuse to accept mail from them.

> That other (unspecified) factors will cause many legitimate domains to
publish records with "+all".
I don't believe it.  I certainly haven't seen anyone on this list claim
that they intend to publish a "+all".

> That SenderID will cause the normal, person-to-person email message to
use something other than PRA == 2822 From == bounce address.
I don't believe this either.  Is there any support for this proposition?
If SenderID forces a change, then what will it change to?

> That all problems are solved if we merely implement
draft-otis-marid-mpr-00.
I (and many others on the group) disagree, for reasons stated many times
previously.
 
-- Jim Lyon

---

From: "Douglas Otis" <[email-masked]>
Date: Sun, 29 Aug 2004 00:22:05 -0700 (PDT)

On Fri, Aug 27, 2004 2:22 pm Jim Lyon wrote:
> On Thu, 26 Aug 2004 15:00:54 -0700 Douglas Otis wrote:
>> On Thu, 2004-08-26 at 11:27, Jim Lyon wrote:
>>> John points out that a forger can defeat SenderID checks by inserting a
>>> Resent-From (or similar) header that references either himself a domain
>>> that hasn't published a SenderID record.
>>>
>>> He goes on to suggest possible ameliorations, including EHLO checks
>>> and/or classic SPF checks using MAIL-FROM.
>>>
>>> He's right that there's a potential problem, but I think he got the
>>> wrong amelioration.
>>>
>>> If there's consensus that a change is required, I would recommend:
>>>
>>> Whenever the PRA is not equal to the 2822 "From", and the SenderID
>>> result is anything other than "pass", and at least 6 months have elapsed
>>> since SenderID became a Proposed Standard, then the message SHOULD be
>>> treated as forged.
>>
>> The reference could be from any domain that provides an "open-ended"
>> record.  The referenced record could be from a "throw-away" domain as a
>> means to still spoof _ANY_ RFC2822 From Mailbox Domain.  As checks
>> become more stringent, more domains may be tempted to publish "+all"
>> records to quell picayune refusals.  Reputation services will become
>> inundated and ineffectual due to lack of Sender-ID identity
>> authentication.  Will Sender-ID really force the world to publish highly
>> problematic records as pertaining to reputation services?
>
> publish records with "+all". I don't believe it. I certainly haven't seen
> anyone on this list claim that they intend to publish a "+all".

Why is there a "+all" when no one intends to use this notation?  Now you
suggest when they do, they'll get a bad reputation.  If reputation is
based upon the IP address, as you previously suggested, using a "+all"
would not affect the IP address.  It could easily be a dare, "Declare this
domain as a spammer on this basis, and they'll see you in court."  By
having "+all" in the standard, it plainly implies "Don't compare this
domain's mail to their  list of MTA IP addresses."  The same problem
exists with "?all", as long as this also is accepted, this raises the same
question, why?  The standard is allowing these settings.  This deserves a
better explanation than no one will use it, and, if they do, their mail
will be blocked.

>>> Reasons for this proposal:
>>>
>>> 1. For most instances of personal mail, PRA == 2822 From == bounce
>>> address, and none of these issues apply.  They only apply in the cases
>>> of specialized agents like forwarders, list servers, third-party mailers
>>> and similar.
>>
>> Sender-ID will likely invite such assumptions to change.  From providers
>> dealing with customers expecting to send mail from their networks, the
>> norm could easily become inclusion of the Resent-From header.  This
>> "every field is the same" model does not fit for large amounts mail and
>> will impose exceptional problems for most domains to confront.
>

As I said, ISPs not wishing to endure costs of training their customer
base to quit using their return addresses and are forced by those that
decide to refuse to accept mail with lists using of "+all" or "?all".  The
solution is rather obvious.  Add a Resent-From header that can be
comprehensively defined in a "closed" list that is independent of the
RFC2822 From header.  There would be virtually no difference in the scope
of this identity from that returned by CSV, except that the name obtained
from CSV has been authenticated without making unverifiable assumptions of
the Mail Channel.

>>> 2. It's reasonable to hold specialized agents to a higher standard than
>>> the rest of the E/Mail community (by requiring a "pass" instead of
>>> merely the absence of a "fail", for instance.)
>>
>> This could create a deployment reaction of having Resent-From included
>> routinely to ameliorate a long list of potential problems.  Once that
>> becomes the norm, EHLO authentication and authorization would then
>> provide the same identity.  If one were to follow this logic of all
>> fields are normally the same, only authenticating and confirming
>> authorization of the EHLO domain arrives at the same identity with much
>> less chance of this identity being spoofed!
>>
>>> 3. When the set of documents hits Proposed Standard, many of the
>>> legitimate specialized agents won't yet be in compliance.  But as a
>>> whole, it's a well-managed community that can move fairly quickly.
>>
>> How will they move?  Where are we going and why are we in this
>> hand-basket? : )  Will they re-train their customers or add a
>> Resent-From?
>>
>>> Reasons against EHLO or bounce address:
>>>
>>> 1. EHLO tells you a name for the sending MTA.  But it gives you no idea
>>> whether that MTA is authorized to act on behalf of the name mentioned in
>>> the message he's sending.  It seems therefore to be irrelevant.
>>
>> Seems irrelevant?  There you go, blaming the message rather than the
>> messenger.  : )
>>
>> It is a matter of first establishing accountability.  The assumptions
>> used to validate a Sender-ID identity will not allow the Sender-ID
>> identity to be held accountable.
>>
>> A simple scheme to impose a Mail Channel prescription upon either the
>> RFC2821 MAIL FROM or the RFC2822 From is illustrated in this draft:
>>
>> http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt
>>
>> Accountability is established first, and this scales well for then
>> prescribing the Mail Channel.  The use of the prescription is for
>> authorization, never authentication.
>>
>>> 2. bounce address tells you who wants to know if the message isn't
>>> delivered. It's also irrelevant when deciding whether the MTA is
>>> authorized to act of behalf of the name mentioned in the message he's
>>> sending.
>>>
>> By also allowing a Mail Channel prescription for the MAIL FROM Mailbox
>> Domain would curtail bounce traffic.  The use of reputation services can
>> not abate this type of traffic.  Again, I refer you back to the MPR
>> draft as how this type of restriction can be imposed while not requiring
>> sequential DNS lookups.
>
> draft-otis-marid-mpr-00. I (and many others on the group) disagree, for
> reasons stated many times previously.

I would think for Last-Call these reasons would be restated on your behalf.

-Doug