At 09:45 -0700 on 04/30/2007, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote about
Re: "for" clause on Received: header field:
>The problem I see with the matching approach, aside from the obious overhead,
>is while you can assume that a successful match to, say, a To: field means it
>is OK to expose that recipient address in a for clause, not finding
>any matches
>doesn't mean the address has bcc semantics. So you end up presenting
>the subset
>of the active recipient list that happen not to have been transformed by
>forwarding/routing activites in ways that prevent matching. The result makes
>for clause disppear in prcecisely the cases where it is most useful for
>debugging purposes: When transformation of the recipient addresses by
>forwarding/routing has led to a mismatch between what's in the header and
>what's in the envelope.
The solution to the matching issue is simple. If you are the ultimate
receiver domain (ie: Example.com for mail addressed to
*(_at_)example(_dot_)com), just clone the message so there is a separate copy
for each Rcpt-To address and place the appropriate address into the
for clause of each cloned message - IOW: Act as a SMTP Server that is
designed to not group multiple Rcpt-To commands into an outgoing
email message even though the Mail-To's point at the same MX Server.
This simple solution only works if you're willing to eat the disk space and/or
bandwidth it consumes. When dealing with large local distributions which for
some companies can run into tens of thousands of recipients for a single
message, this is an absolute and complete nonstarter. Of course you can put a
threshold on the maximum recipients before separate copies are disabled, but
the cases where for clauses are most useful are those involving large, complex
lists.
A more complex solution is to store separate headers (or even parts of headers)
for each copy but share the message body.
You can get even trickier and look for common message bodies or parts between
different messages and if you find them eliminate the duplicate.
Ned