[Mimedefang] Like action_replace_with_url(), but not quite

[Nathan Findley]

On 08/31/2012 04:39 AM, Philip Prindeville wrote:
> I have a gateway that handles attachments that only make sense for registered users who have the appropriate plugin.
>
> If we detect a user that's not registered is a recipient (possibly one of several), then we need to customize a message just for that user with the attachment stripped and replaced instead with a message saying, "Visit this URL to install the plug-in, register, and pick up your attachment."
>
> We want something like action_replace_with_url() but not quite.
>
> First, the putting the attachment into a lookaside server we'll handle ourselves (or rather, it's already handled).
>
> So I just need to generate the URL, format a replacement entity, call action_rebuild(), and ensure that this message gets delivered to the one recipient (even if the original @Recipients > 1).
>
> How do I go about most efficiently pulling him out of the group-delivery instance and generate a new unique message just for him?
>
> I can't use stream_by_recipient() because I don't know which attachments need to be removed until I hit filter() and not filter_begin().
>
> Note also that each attachment of the proprietary type would need to be uniquely rewritten, but the end-user still only gets one (per-user unique) message.
>
> An example: message M comes along with recipients r1, r2, and r3.
>
> It also has attachments A, B, and C.
>
> It will get delivered to {r1, r2} as is, but it will also be rewritten as: M(r3) to r3 with attachments A, B, C replaced with new entities A(r3), B(r3), C(r3) which r3 can then individually retrieve.
>
> What's the best way to do this?
>
I know that the documentation states that stream_by_recipient should 
only be used in filter_begin, but isn't that only a suggestion based on 
overloading a server? Looking through the code it isn't really clear to 
me why it would be a problem from a technical standpoint.

 From our more knowledgeable mimedefang users, I would appreciate an 
explanation about what is happening in the mimedefang.pl 
"resend_message_specifying_mode" method. The child execs sendmail. The 
message data is sitting in the child process's STDIN, correct? It is a 
little hard for me to follow why data on STDIN would be properly passed 
to the exec method that calls sendmail. I apologize for the (no doubt) 
stupidity of this question.

Small snippet:

# In curlies to silence Perl warning...
my $sm;
$sm = $Features{'Path:SENDMAIL'};
{ exec($sm, @cmd); } <-- how is sendmail receiving the contents of the 
message? I don't see any explicit piping happening.

Nate

-- 
システムマネージャー/開発責任者
Zenlok株式会社