ietf-mxcomp
[Top] [All Lists]

RE: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages

2004-08-27 16:43:17

On Fri, 2004-08-27 at 17:48, Jim Lyon wrote: 
On Thursday, August 26, 2004 at 4:20 PM, Mark Shewmaker wrote (regarding
the need to generate a DSN if 7 conditions hold): 

The only way to solve this problem would be to allow for an override
of the must-accept-100-recipients requirement in RFC 2821.

True. This would help, and is probably a good idea. But it's outside the
scope of MARID.

If we can't solve the problem within the scope of MARID, that would
leave us with requiring complying implementations to open themselves to
what I consider a security hole.

However, I just realized that I made a mistake that's caused me to frame
the issue incorrectly, and this leads to a solution that I hope is
within the scope of MARID.

Here is my original objection, shortened considerably, written such that
it includes my mistake:

    1.  RFC 2821 says we must accept-and-deliver, reject, or send DSNs.
    2.  RFC 2821 also says we need to accept at least 100 recipients.

    But if we accept recipients with differing white lists, and we obey
    (1) and (2) above, we expose ourselves to a vulnerability in the
    7-conditions case 

    The only solutions to that are to violate either (1) or (2).

    I don't like the notion of violating (1), as I consider it
    lying/deceitful behavior, so I would prefer to violate (2).

    So I would like something in SenderID that says it's okay
    to violate (2) in this case.

My error was that requirement (2) isn't what I thought and stated
above.  Quoting RFC2821:

   |recipients buffer 
   |   The minimum total number of recipients that must be buffered is
   |   100 recipients.  Rejection of messages (for excessive recipients)
   |   with fewer than 100 RCPT commands is a violation of this
   |   specification.

But we wouldn't be rejecting messages because there are excessive
recipients, we'd really be rejecting them because they are, well,
incompatible recipients.

A fine distinction, perhaps, but I take it to mean that we can reject at
the first recipient with a differing white list, and not only would we
not be in violation of RFC 2821, we'd not have to have Sender ID
overrule this section of RFC 2821 either.

Just instead of claiming the reason being a "too many recipients" error,
claim something more appropriate to for a recipient filtering
incompatibility problem, maybe a 4.7.0 perhaps.  (I'm not sure what
would be the most appropriate response code.)

So, is that suggestion something that could be included within SenderID,
perhaps in a security-considerations section?  Or perhaps a
best-current-practices document?

Otherwise we're effectively suggesting that folks open themselves up to
an avoidable vulnerability without pointing out how it's avoidable.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com