At 18:59 -0700 on 04/30/2007, Ned Freed wrote about Re: "for" clause
on Received: header field:
> > 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.
The above quote was mine. I fail to see where there is any massive
disk space or bandwidth usage if implemented correctly. There HAS to
be some ultimate SMTP Server that is delivering the message to the
user's POP/IMAP Mailbox. How hard is it for THAT SMTP Server (if not
the ones that is handing the message off it it) to put the for clause
into the Received Header as it places the cloned copy of the message
into the user's mailbox?
This is the second option I mentioned, which is for the IMAP server to
store the common part of the message for all users but to also have
a user-dependent part.
But to answer your question, whether or not it is hard depends on the
store design. In some stores it is simple, in some it is next to impossible,
and for some it adds so much complexity and fragility that it really isn't
an option.
The delivery SMTP Server MUST clone the
message at that point anyway (and it takes no extra disk space or
bandwidth for the INCOMING message).
Not if it is properly designed it doesn't. We routinely end up storing
a single copy of a message with tens of thousands of recipients.
How far back along the chain of
SMTP Servers doing hand-off/relay between the MX Server that accepts
the message and the SMTP Delivery server that places it into the
mailbox (or redirects the message due to a .forward) you place the
SMTP Server that does the actual cloning is an implementation
decision.
You're right in saying it is an implementation decision, but you're making
assumptions about how things have to be implemented that just aren't true
for high-end server architectures, including but not limited to ours.
However, since this has almost nothing to do with the matter at hand I'm
going to stop here rather than get into how we implement all this.
Ned