send.publickey seems to allow anyone with an account on the server (subscribed or not) or any request with a proper DKIM sig to send. I guess that's slightly better than allowing anyone (send.public) but why not use a sceneri that does: is_subscriber -> request_auth or checks DKIM? I can't think of a case where someone sending to a list would authenticate with a different account than the subscribed one.
send.privateorpublickey allows subscribers to send without auth (#362) but for non-subscribers it does request_auth, like the above just requiring having an account on the server(subscribed or not).
Maybe I am missing something about these? If not maybe they can start to go away?
Version
6.2.32 and older.
Installation method
Expected behavior
Actual behavior
Additional information
send.publickey seems to allow anyone with an account on the server (subscribed or not) or any request with a proper DKIM sig to send. I guess that's slightly better than allowing anyone (send.public) but why not use a sceneri that does:
is_subscriber -> request_author checks DKIM? I can't think of a case where someone sending to a list would authenticate with a different account than the subscribed one.send.privateorpublickey allows subscribers to send without auth (#362) but for non-subscribers it does request_auth, like the above just requiring having an account on the server(subscribed or not).
Maybe I am missing something about these? If not maybe they can start to go away?
Version
6.2.32 and older.
Installation method
Expected behavior
Actual behavior
Additional information