[Mailmunge] Mailmunge API discussion

[Dianne Skoll]

On Wed, 18 May 2022 00:23:25 -0500
Richard Laager via Mailmunge <mailmunge at lists.mailmunge.org> wrote:

[...]

> Typo: stray quote in: $self->action_discard($ctx"); return;

Thanks; fixed.

[...]

> I'd probably tighten this to -1 specifically (rather than the more 
> general "negative"), at least in the docs. The idea for -1 as the
> magic value is that it is consistent with negative array indexes.

Fixed that too (in action_insert_header)

> 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.

[...]

> 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.

> 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.  Most of the time,
you want to add or remove a recipient or two, not do a wholesale replacement.

If you ever *do* want to do wholesale replacement, it's not that hard
using the existing API.

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.

[...]

> We wait to load the SpamAssassin module until it is actually going to
> be used.  MIMEDefang's built-in behavior is to load the SpamAssassin
> module right away.  By waiting, we reduce the memory consumption of
> workers that never call SpamAssassin.  For example, workers that
> happen to only handle filter_sender and filter_recipient checks.

I don't think this is worthwhile.  Mailmunge makes no guarantee as to which
workers are handed which pieces of work, so doing this sort of thing lazily
is unlikely to buy you much.  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.

> 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.

[...]

> 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.

> I know you stopped using GitHub for $reasons. I'm not looking to
> debate those reasons. But it would be nice to have some issue tracker
> and pull request process. Then I could be submitting these things as
> separate issues, and for some of them, pull requests.

As mentioned in an earilier email, I made a GitHub repo at
https://github.com/dfskoll/mailmunge

Regards,

Dianne.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.mailmunge.org/pipermail/mailmunge/attachments/20220519/bd9af1ea/attachment.sig>