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株式会社
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
