(n)upas/ml quirks

(n)upas/ml quirks

[stanley lieber]

The presence of a host!user formatted address in a mailing list's address-list file seems to prevent an incoming message from being delivered to the list.

I have not had a chance to investigate this further. The empirical test was to remove the host!user address from the 9front mailing list's address-list file, at which time messages stopped being dropped silently and resumed being delivered to list members.

sl
‎

Re: [9front] (n)upas/ml quirks

[cinap_lenrek]

any messages in /sys/log/mail about this address?

--
cinap

Re: [9front] (n)upas/ml quirks

[cinap_lenrek]

i looked into mail/ml and all it does is to call upas/send with
the list of addresses as arguments and the mail to be send is
read from standard input. upas/send resolves each destination
individually... not clear why this would break all the destinations.

--
cinap

Re: [9front] (n)upas/ml quirks

[cinap_lenrek]

shouldn't all the outgoing mails be queued anyway? and processed
asynchronously? can you try and run upas/send with the bogus
destination in question and see what happens?

--
cinap

Re: [9front] (n)upas/ml quirks

[stanley lieber]

I'll try all these suggestions. I ran out of time yesterday.

One note:

The offending address was actually an *unsubscribe*:

        !host!username

The original subscribe appeared in this format:

        user@host

I was monitoring logs while sending test messages and it appeared‎
that the message was accepted into the system but was never
sent out to address-list.

It also appeared that the list's pipeto was not fully processed; ‎some
of the intermediate files created by the list's pipeto script never got
created (until I removed the !host!user line from address-list). This
makes me wonder if the failure occurred before sending was even
attempted.

As I say, I ran out of time, but the seeming failure to handle the
address-list seemed like a clue. I think I recall previous observations
of a similar failure: a mismatch between subscribes and unsunscribes
results in failure, generally.

I'll have more medium- to low-quality observations to report tonight.

sl

Re: [9front] (n)upas/ml quirks

[stanley lieber]

I'll try all these suggestions. I ran out of time yesterday.

One note:

The offending address was actually an *unsubscribe*:

        !host!username

The original subscribe appeared in this format:

        user@host

I was monitoring logs while sending test messages and it appeared
that the message was accepted into the system but was never
sent out to address-list.

It also appeared that the list's pipeto was not fully processed; ‎some
of the intermediate files created by the list's pipeto script never got
created (until I removed the !host!user line from address-list). This
makes me wonder if the failure occurred before sending was even
attempted.

As I say, I ran out of time, but the seeming failure to handle the
address-list seemed like a clue. I think I recall previous observations
of a similar failure: a mismatch between subscribes and unsunscribes
results in failure, generally.

I'll have more medium- to low-quality observations to report tonight.

sl

Re: [9front] (n)upas/ml quirks

[cinap_lenrek]

lines starting with ! are removed entries... the address
list is just a log of added and removed email addresses...

i dont see why using host!user syntax would not work... rewrite
should handle this and convert it back to user@host.

--
cinap

Re: [9front] (n)upas/ml quirks

[cinap_lenrek]

a mismatch between subscribes and unsunscribes results in failure, generally.

do you mean like if theres a unsubscribe but no matching subscribe it
results in the mailinglist being broken?

or you mean that when the strings do not match the sender is not removed
from the mailinglist?

--
cinap