[Mailmunge] Mailmunge API discussion

[Richard Laager]

On 5/19/22 12:51, Dianne Skoll via Mailmunge wrote:
> On Wed, 18 May 2022 00:23:25 -0500
> Richard Laager via Mailmunge <mailmunge at lists.mailmunge.org> wrote:

>> You can't fix this without breaking compatibility, but it seems that
>> action_change_header() and action_delete_header() are 1-indexed while
>> action_insert_header() is 0-indexed. Is there a good reason for that?
> 
> Well, inserting a header at position N inserts after the existing header
> at that position.  Inserting a position 1 would insert after the
> first header, so the only way to insert before that header would be
> to insert after position 0.

Sure, that makes sense. Plus, I'm a programmer; I have no problem with 
0-indexed. :)

I guess I was more-so asking why change and delete are 1-indexed (if I'm 
indeed correct in understanding that they are).

>> Should this be memoized (cached) so that multiple calls to e.g.
>> canonical_recipients() don't have to redo the work every time?
>> Granted, I'm sure canonical_email() is relatively cheap, but still.
> 
> Nah, don't think it's worth it.  The caller can always hang on to the array
> of canonical addresses if necessary.

Fair enough. In my case, I'll probably have to do it myself anyway, as 
I'll probably need to correlate with the non-canonical version for 
deleting them (when needed).

>> How would this intersect with the idea of sender/recipients being
>> made mutable?
> 
> It wouldn't, because I'm not going to implement that.  I thought about this
> and don't see an advantage over the way it's done now.

Fair enough.

> Most of the time,
> you want to add or remove a recipient or two

Right, I was always talking about modifying individual recipients in the 
list.

> And for changing the sender, I see no real advantage of:
> 
>      $ctx->sender('<new_sender at example.com>');
> 
> over
> 
>      $self->change_sender($ctx, '<new_sender at example.com>');
> 
> other than a bit less typing.

I mean, yeah, that and simplification is the benefit. But it's of less 
consequence if only the sender can be changed and not the recipients. So 
I'll let this go.

> I don't think this is worthwhile.  Mailmunge makes no guarantee as to which
> workers are handed which pieces of work

This must have been dropped then, either in the MIMEDefang -> Mailmunge 
transition, or at some previous point in MIMEDefang.

I had to check to see if I was crazy. MIMEDefang 2.57-BETA-1 said:

  * mimedefang-multiplexor: New scheduling algorithm tries to keep
    commands "sticky".  For example, when looking for a worker to run
    "recipok", we prefer to use a worker that recently ran "recipok".

> In fact, if you're using embedded Perl, there's
> an argument for loading everything before the child is forked to avoid
> having to run all the parsing and initialization code in each child.

Agreed.

So I'll probably drop this "optimization". Even if it's still helping 
(which we agree it might not be), it's probably not a big deal these 
days vs in the past when RAM was more scarce.

>> The actual code says:
>>       # This is synthesize_received_header() inlined, except that if
>>       # $local_relay is set, we add "(authenticated bits=0)" to the
>>       # "Received:" header.
> 
> In Mailmunge, I suppose you could override synthesize_received_header
> in your own filter.  That's one of the advantages of the OO-based API
> rather than global functions.

Agreed. (If I need the change, which it sounds like I don't.)

>> A) Can I set $ctx->sendmail_macro('auth_authen') if my IP-check
>> passes?
> 
> Yep.  It's a setter, as in: $ctx->sendmail_macro('auth_authen', 'whatever');
> And SpamAssassin does seem to recognize "ESMTPA" to mean authenticated.

-- 
Richard