Accessing the sending user from a canonical(5) table

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
On 10/6/20 4:23 PM, Wietse Venema wrote:

> Demi M. Obenour:
>> On 10/6/20 12:46 PM, Wietse Venema wrote:
>>> For me, 'not found' also includes the case that the user is not found
>>> in the passwd file.
>>
>> By "allow 'not found' users", do you mean that such users will
>> automatically be granted access, or that they will still be looked up
>> (perhaps by numeric UID) in local_sender_login_maps?
>
> Postfix sendmail looks up the username only if no sender was specified
> with -f, and terminates if the username cannot be found. That behavior
> should not change by default.
That's fine.

> If the feature is turned on then there should probably be a
> default action for users not listed in the table (deny or allow).
> Its not going to be pretty when only the numerical UID is avaialble
> (a 1:1 mapping username->sender would not make sense).

What about defaulting to allow if local_sender_login_maps has its
default value, and deny otherwise?  That keeps the current default
behavior, while still allowing administrators to lock it down.

In the unlikely event that the table lookup itself fails, I believe
that postdrop should log an error and exit.  That avoids accidental
security holes due to temporary failures.

> Wietse
Sincerely,

Demi

OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
Demi M. Obenour:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.

> On 10/6/20 4:23 PM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> On 10/6/20 12:46 PM, Wietse Venema wrote:
> >>> For me, 'not found' also includes the case that the user is not found
> >>> in the passwd file.
> >>
> >> By "allow 'not found' users", do you mean that such users will
> >> automatically be granted access, or that they will still be looked up
> >> (perhaps by numeric UID) in local_sender_login_maps?
> >
> > Postfix sendmail looks up the username only if no sender was specified
> > with -f, and terminates if the username cannot be found. That behavior
> > should not change by default.
>
> That's fine.
>
> > If the feature is turned on then there should probably be a
> > default action for users not listed in the table (deny or allow).
> > Its not going to be pretty when only the numerical UID is avaialble
> > (a 1:1 mapping username->sender would not make sense).
>
> What about defaulting to allow if local_sender_login_maps has its
> default value, and deny otherwise?  That keeps the current default
> behavior, while still allowing administrators to lock it down.

The action (deny) for unmatched users should not depend on the
(non-empty) local_sender_login_maps value.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
On 10/8/20 8:25 AM, Wietse Venema wrote:

> Demi M. Obenour:
>> On 10/6/20 4:23 PM, Wietse Venema wrote:
>>> If the feature is turned on then there should probably be a
>>> default action for users not listed in the table (deny or allow).
>>> Its not going to be pretty when only the numerical UID is avaialble
>>> (a 1:1 mapping username->sender would not make sense).
>>
>> What about defaulting to allow if local_sender_login_maps has its
>> default value, and deny otherwise?  That keeps the current default
>> behavior, while still allowing administrators to lock it down.
>
> The action (deny) for unmatched users should not depend on the
> (non-empty) local_sender_login_maps value.
Should this be a configuration option?  Alternatively, we could look
up unknown UIDs as strings, perhaps prefixed with a character that is
not valid in an email address.  Other places in Postfix use "unknown"
to mean something similar.

We could also have local_sender_login_maps be empty by default, and
have unmatched users be allowed by default if and only if it is empty.

> Wietse

Demi


OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
Demi M. Obenour:

> On 10/8/20 8:25 AM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> On 10/6/20 4:23 PM, Wietse Venema wrote:
> >>> If the feature is turned on then there should probably be a
> >>> default action for users not listed in the table (deny or allow).
> >>> Its not going to be pretty when only the numerical UID is avaialble
> >>> (a 1:1 mapping username->sender would not make sense).
> >>
> >> What about defaulting to allow if local_sender_login_maps has its
> >> default value, and deny otherwise?  That keeps the current default
> >> behavior, while still allowing administrators to lock it down.
> >
> > The action (deny) for unmatched users should not depend on the
> > (non-empty) local_sender_login_maps value.
>
> Should this be a configuration option?

It is not needed. If someone wants unmatched users to allow all,
just say so:

    local_sender_login_maps = <real login->address map> static:*

This still enforces the allowed email addressesfor users that have
an entry.

If local_sender_login_maps is turned on, indexing with "#" plus the
UID as a string would do the job. It is not like users can arbitrarily
remove their login name from the password file.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
On 10/8/20 3:19 PM, Wietse Venema wrote:

> Demi M. Obenour:
>> On 10/8/20 8:25 AM, Wietse Venema wrote:
>>> Demi M. Obenour:
>>>> On 10/6/20 4:23 PM, Wietse Venema wrote:
>>>>> If the feature is turned on then there should probably be a
>>>>> default action for users not listed in the table (deny or allow).
>>>>> Its not going to be pretty when only the numerical UID is avaialble
>>>>> (a 1:1 mapping username->sender would not make sense).
>>>>
>>>> What about defaulting to allow if local_sender_login_maps has its
>>>> default value, and deny otherwise?  That keeps the current default
>>>> behavior, while still allowing administrators to lock it down.
>>>
>>> The action (deny) for unmatched users should not depend on the
>>> (non-empty) local_sender_login_maps value.
>>
>> Should this be a configuration option?
>
> It is not needed. If someone wants unmatched users to allow all,
> just say so:
>
>      local_sender_login_maps = <real login->address map> static:*
>
> This still enforces the allowed email addressesfor users that have
> an entry.
>
> If local_sender_login_maps is turned on, indexing with "#" plus the
> UID as a string would do the job. It is not like users can arbitrarily
> remove their login name from the password file.
Here is an updated diff which implements this idea.  It also splits out
the FROM access check into its own function, and uses var_rcpt_delim
instead of hard-coding "+".  $mail_owner is now allowed to send mail
as any user.

> Wietse

Demi

diff -ur ../postfix-3.5.7-old/src/global/mail_params.h ../postfix-3.5.7/src/global/mail_params.h
--- ../postfix-3.5.7-old/src/global/mail_params.h 2020-10-05 18:52:49.518000000 -0400
+++ ../postfix-3.5.7/src/global/mail_params.h 2020-10-05 18:10:32.641000000 -0400
@@ -1667,6 +1667,10 @@
  #define DEF_SMTPD_SASL_TYPE DEF_SERVER_SASL_TYPE
  extern char *var_smtpd_sasl_type;
 
+#define VAR_LOCAL_SND_AUTH_MAPS "local_sender_login_maps"
+#define DEF_LOCAL_SND_AUTH_MAPS "static:*"
+extern char *var_local_snd_auth_maps;
+
  #define VAR_SMTPD_SND_AUTH_MAPS "smtpd_sender_login_maps"
  #define DEF_SMTPD_SND_AUTH_MAPS ""
  extern char *var_smtpd_snd_auth_maps;
diff -ur ../postfix-3.5.7-old/src/postdrop/postdrop.c ../postfix-3.5.7/src/postdrop/postdrop.c
--- ../postfix-3.5.7-old/src/postdrop/postdrop.c 2020-10-05 18:52:49.518000000 -0400
+++ ../postfix-3.5.7/src/postdrop/postdrop.c 2020-10-09 12:53:43.249000000 -0400
@@ -114,6 +114,7 @@
  #include <stdio.h> /* remove() */
  #include <string.h>
  #include <stdlib.h>
+#include <inttypes.h>
  #include <signal.h>
  #include <errno.h>
  #include <warn_stat.h>
@@ -147,6 +148,10 @@
  #include <rec_attr_map.h>
  #include <mail_parm_split.h>
  #include <maillog_client.h>
+#include <maps.h>
+#include <mail_addr_find.h>
+#include <strip_addr.h>
+#include <mypwd.h>
 
  /* Application-specific. */
 
@@ -167,9 +172,13 @@
    * Local mail submission access list.
    */
  char   *var_submit_acl;
+char   *var_local_snd_auth_maps;
+char   *var_rcpt_delim;
 
  static const CONFIG_STR_TABLE str_table[] = {
      VAR_SUBMIT_ACL, DEF_SUBMIT_ACL, &var_submit_acl, 0, 0,
+    VAR_LOCAL_SND_AUTH_MAPS, DEF_LOCAL_SND_AUTH_MAPS, &var_local_snd_auth_maps, 0, 0,
+    VAR_RCPT_DELIM, DEF_RCPT_DELIM, &var_rcpt_delim, 0, 0,
      0,
  };
 
@@ -220,6 +229,65 @@
      postdrop_sig(0);
  }
 
+/*
+ * postdrop_check_access - check if a user is authorized to send mail as
+ * the envelope sender
+ */
+static void postdrop_check_access(VSTRING *const buf, uid_t const uid) {
+    MAPS    *local_sender_login_maps;
+    struct mypasswd *username;
+    const char *owners;
+    char   *saved_owners, *cp, *name, *stripped, *stripped_copy, username_buf[22];
+    char   *pw_name;
+    int     found = 0;
+
+    /* Root and $mail_owner are always allowed to send as anyone. */
+    if (uid == 0 || uid == var_owner_uid)
+ return;
+
+    /*
+     * Get the username.
+     */
+    if ((username = mypwuid(uid)) != NULL)
+ pw_name = username->pw_name;
+    else {
+ int status = snprintf(username_buf, sizeof username_buf, "#%"PRIu64, (uint64_t)uid);
+ if (status < 0 || status >= sizeof username_buf)
+    msg_fatal("snprintf");
+ pw_name = username_buf;
+    }
+
+    local_sender_login_maps = maps_create(VAR_SMTPD_SND_AUTH_MAPS,
+  var_local_snd_auth_maps,
+  DICT_FLAG_FOLD_FIX |
+  DICT_FLAG_UTF8_REQUEST |
+  DICT_FLAG_NO_PROXY |
+  DICT_FLAG_NO_UNAUTH);
+
+    if (vstring_memchr(buf, '\0') != NULL)
+ msg_fatal("uid=%ld: NUL in FROM", (long) uid);
+    if ((owners = maps_find(local_sender_login_maps, pw_name, 0)) == NULL)
+ msg_fatal("uid=%ld: not found in local_sender_login_maps", (long) uid);
+    if (local_sender_login_maps->error != 0)
+ msg_fatal("map lookup succeeded, but error set");
+    if (strcmp(owners, "*") == 0)
+ return;
+    if ((stripped = stripped_copy = strip_addr_internal(vstring_str(buf), NULL, var_rcpt_delim)) == NULL)
+ stripped = vstring_str(buf);
+    cp = saved_owners = mystrdup(owners);
+    while ((name = mystrtok(&saved_owners, CHARS_COMMA_SP)) != 0) {
+ if (strcmp(stripped, name) == 0) {
+    found = 1;
+    break;
+ }
+    }
+    if (!found)
+ msg_fatal("uid=%ld: does not own address %s", (long) uid, vstring_str(buf));
+    if (stripped_copy != NULL)
+ myfree(stripped_copy);
+    myfree(cp);
+}
+
  MAIL_VERSION_STAMP_DECLARE;
 
  /* main - the main program */
@@ -316,16 +384,6 @@
      get_mail_conf_str_table(str_table);
 
      /*
-     * Mail submission access control. Should this be in the user-land gate,
-     * or in the daemon process?
-     */
-    mail_dict_init();
-    if ((errstr = check_user_acl_byuid(VAR_SUBMIT_ACL, var_submit_acl,
-       uid)) != 0)
- msg_fatal("User %s(%ld) is not allowed to submit mail",
-  errstr, (long) uid);
-
-    /*
       * Stop run-away process accidents by limiting the queue file size. This
       * is not a defense against DOS attack.
       */
@@ -369,6 +427,16 @@
      /* End of initializations. */
 
      /*
+     * Mail submission access control. Should this be in the user-land gate,
+     * or in the daemon process?
+     */
+    mail_dict_init();
+    if ((errstr = check_user_acl_byuid(VAR_SUBMIT_ACL, var_submit_acl,
+       uid)) != 0)
+ msg_fatal("User %s(%ld) is not allowed to submit mail",
+  errstr, (long) uid);
+
+    /*
       * Don't trust the caller's time information.
       */
      GETTIMEOFDAY(&start);
@@ -429,8 +497,10 @@
  if (rec_type == REC_TYPE_TIME)
     continue;
  /* Check these at submission time instead of pickup time. */
- if (rec_type == REC_TYPE_FROM)
+ if (rec_type == REC_TYPE_FROM) {
+    postdrop_check_access(buf, uid);
     from_count++;
+ }
  if (rec_type == REC_TYPE_RCPT)
     rcpt_count++;
  /* Limit the attribute types that users may specify. */
@@ -477,7 +547,7 @@
  if (rec_type == REC_TYPE_END)
     break;
      }
-    vstring_free(buf);
+    buf = vstring_free(buf);
 
      /*
       * As of Postfix 2.7 the pickup daemon discards mail without recipients.


OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
On 10/9/20 1:06 PM, Demi M. Obenour wrote:

> On 10/8/20 3:19 PM, Wietse Venema wrote:
>> Demi M. Obenour:
>>> On 10/8/20 8:25 AM, Wietse Venema wrote:
>>>> Demi M. Obenour:
>>>>> On 10/6/20 4:23 PM, Wietse Venema wrote:
>>>>>> If the feature is turned on then there should probably be a
>>>>>> default action for users not listed in the table (deny or allow).
>>>>>> Its not going to be pretty when only the numerical UID is avaialble
>>>>>> (a 1:1 mapping username->sender would not make sense).
>>>>>
>>>>> What about defaulting to allow if local_sender_login_maps has its
>>>>> default value, and deny otherwise?  That keeps the current default
>>>>> behavior, while still allowing administrators to lock it down.
>>>>
>>>> The action (deny) for unmatched users should not depend on the
>>>> (non-empty) local_sender_login_maps value.
>>>
>>> Should this be a configuration option?
>>
>> It is not needed. If someone wants unmatched users to allow all,
>> just say so:
>>
>>      local_sender_login_maps = <real login->address map> static:*
>>
>> This still enforces the allowed email addressesfor users that have
>> an entry.
>>
>> If local_sender_login_maps is turned on, indexing with "#" plus the
>> UID as a string would do the job. It is not like users can arbitrarily
>> remove their login name from the password file.
>
> Here is an updated diff which implements this idea.  It also splits out
> the FROM access check into its own function, and uses var_rcpt_delim
> instead of hard-coding "+".  $mail_owner is now allowed to send mail
> as any user.
Looks like Thunderbird mangled the whitespace.  Here is another attempt:

diff -ur ../postfix-3.5.7-old/src/global/mail_params.h ../postfix-3.5.7/src/global/mail_params.h
--- ../postfix-3.5.7-old/src/global/mail_params.h 2020-10-05 18:52:49.518000000 -0400
+++ ../postfix-3.5.7/src/global/mail_params.h 2020-10-05 18:10:32.641000000 -0400
@@ -1667,6 +1667,10 @@
 #define DEF_SMTPD_SASL_TYPE DEF_SERVER_SASL_TYPE
 extern char *var_smtpd_sasl_type;
 
+#define VAR_LOCAL_SND_AUTH_MAPS "local_sender_login_maps"
+#define DEF_LOCAL_SND_AUTH_MAPS "static:*"
+extern char *var_local_snd_auth_maps;
+
 #define VAR_SMTPD_SND_AUTH_MAPS "smtpd_sender_login_maps"
 #define DEF_SMTPD_SND_AUTH_MAPS ""
 extern char *var_smtpd_snd_auth_maps;
diff -ur ../postfix-3.5.7-old/src/postdrop/postdrop.c ../postfix-3.5.7/src/postdrop/postdrop.c
--- ../postfix-3.5.7-old/src/postdrop/postdrop.c 2020-10-05 18:52:49.518000000 -0400
+++ ../postfix-3.5.7/src/postdrop/postdrop.c 2020-10-09 12:53:43.249000000 -0400
@@ -114,6 +114,7 @@
 #include <stdio.h> /* remove() */
 #include <string.h>
 #include <stdlib.h>
+#include <inttypes.h>
 #include <signal.h>
 #include <errno.h>
 #include <warn_stat.h>
@@ -147,6 +148,10 @@
 #include <rec_attr_map.h>
 #include <mail_parm_split.h>
 #include <maillog_client.h>
+#include <maps.h>
+#include <mail_addr_find.h>
+#include <strip_addr.h>
+#include <mypwd.h>
 
 /* Application-specific. */
 
@@ -167,9 +172,13 @@
   * Local mail submission access list.
   */
 char   *var_submit_acl;
+char   *var_local_snd_auth_maps;
+char   *var_rcpt_delim;
 
 static const CONFIG_STR_TABLE str_table[] = {
     VAR_SUBMIT_ACL, DEF_SUBMIT_ACL, &var_submit_acl, 0, 0,
+    VAR_LOCAL_SND_AUTH_MAPS, DEF_LOCAL_SND_AUTH_MAPS, &var_local_snd_auth_maps, 0, 0,
+    VAR_RCPT_DELIM, DEF_RCPT_DELIM, &var_rcpt_delim, 0, 0,
     0,
 };
 
@@ -220,6 +229,65 @@
     postdrop_sig(0);
 }
 
+/*
+ * postdrop_check_access - check if a user is authorized to send mail as
+ * the envelope sender
+ */
+static void postdrop_check_access(VSTRING *const buf, uid_t const uid) {
+    MAPS    *local_sender_login_maps;
+    struct mypasswd *username;
+    const char *owners;
+    char   *saved_owners, *cp, *name, *stripped, *stripped_copy, username_buf[22];
+    char   *pw_name;
+    int     found = 0;
+
+    /* Root and $mail_owner are always allowed to send as anyone. */
+    if (uid == 0 || uid == var_owner_uid)
+ return;
+
+    /*
+     * Get the username.
+     */
+    if ((username = mypwuid(uid)) != NULL)
+ pw_name = username->pw_name;
+    else {
+ int status = snprintf(username_buf, sizeof username_buf, "#%"PRIu64, (uint64_t)uid);
+ if (status < 0 || status >= sizeof username_buf)
+    msg_fatal("snprintf");
+ pw_name = username_buf;
+    }
+
+    local_sender_login_maps = maps_create(VAR_SMTPD_SND_AUTH_MAPS,
+  var_local_snd_auth_maps,
+  DICT_FLAG_FOLD_FIX |
+  DICT_FLAG_UTF8_REQUEST |
+  DICT_FLAG_NO_PROXY |
+  DICT_FLAG_NO_UNAUTH);
+
+    if (vstring_memchr(buf, '\0') != NULL)
+ msg_fatal("uid=%ld: NUL in FROM", (long) uid);
+    if ((owners = maps_find(local_sender_login_maps, pw_name, 0)) == NULL)
+ msg_fatal("uid=%ld: not found in local_sender_login_maps", (long) uid);
+    if (local_sender_login_maps->error != 0)
+ msg_fatal("map lookup succeeded, but error set");
+    if (strcmp(owners, "*") == 0)
+ return;
+    if ((stripped = stripped_copy = strip_addr_internal(vstring_str(buf), NULL, var_rcpt_delim)) == NULL)
+ stripped = vstring_str(buf);
+    cp = saved_owners = mystrdup(owners);
+    while ((name = mystrtok(&saved_owners, CHARS_COMMA_SP)) != 0) {
+ if (strcmp(stripped, name) == 0) {
+    found = 1;
+    break;
+ }
+    }
+    if (!found)
+ msg_fatal("uid=%ld: does not own address %s", (long) uid, vstring_str(buf));
+    if (stripped_copy != NULL)
+ myfree(stripped_copy);
+    myfree(cp);
+}
+
 MAIL_VERSION_STAMP_DECLARE;
 
 /* main - the main program */
@@ -316,16 +384,6 @@
     get_mail_conf_str_table(str_table);
 
     /*
-     * Mail submission access control. Should this be in the user-land gate,
-     * or in the daemon process?
-     */
-    mail_dict_init();
-    if ((errstr = check_user_acl_byuid(VAR_SUBMIT_ACL, var_submit_acl,
-       uid)) != 0)
- msg_fatal("User %s(%ld) is not allowed to submit mail",
-  errstr, (long) uid);
-
-    /*
      * Stop run-away process accidents by limiting the queue file size. This
      * is not a defense against DOS attack.
      */
@@ -369,6 +427,16 @@
     /* End of initializations. */
 
     /*
+     * Mail submission access control. Should this be in the user-land gate,
+     * or in the daemon process?
+     */
+    mail_dict_init();
+    if ((errstr = check_user_acl_byuid(VAR_SUBMIT_ACL, var_submit_acl,
+       uid)) != 0)
+ msg_fatal("User %s(%ld) is not allowed to submit mail",
+  errstr, (long) uid);
+
+    /*
      * Don't trust the caller's time information.
      */
     GETTIMEOFDAY(&start);
@@ -429,8 +497,10 @@
  if (rec_type == REC_TYPE_TIME)
     continue;
  /* Check these at submission time instead of pickup time. */
- if (rec_type == REC_TYPE_FROM)
+ if (rec_type == REC_TYPE_FROM) {
+    postdrop_check_access(buf, uid);
     from_count++;
+ }
  if (rec_type == REC_TYPE_RCPT)
     rcpt_count++;
  /* Limit the attribute types that users may specify. */
@@ -477,7 +547,7 @@
  if (rec_type == REC_TYPE_END)
     break;
     }
-    vstring_free(buf);
+    buf = vstring_free(buf);
 
     /*
      * As of Postfix 2.7 the pickup daemon discards mail without recipients.


OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
Should I submit another patch?  In addition to adding
local_sender_login_maps, I have fixed what appeared to be a bug in
the current postdrop and sendmail commands: root and $mail_owner were
not automatically allowed to submit mail.  Since this is inconsistent
with similar checks elsewhere, I believe it is unintentional.

Sincerely,

Demi

OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Viktor Dukhovni
> On Oct 17, 2020, at 2:55 AM, Demi M. Obenour <[hidden email]> wrote:
>
> Should I submit another patch?  In addition to adding
> local_sender_login_maps, I have fixed what appeared to be a bug in
> the current postdrop and sendmail commands: root and $mail_owner were
> not automatically allowed to submit mail.  Since this is inconsi

I don't see why either "root" or "postfix" should be exempt from
authorized_submit_users.  No such exemption is documented or
intended.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
In reply to this post by Demi M. Obenour
Demi M. Obenour:
> Should I submit another patch?  In addition to adding
> local_sender_login_maps, I have fixed what appeared to be a bug in
> the current postdrop and sendmail commands: root and $mail_owner were
> not automatically allowed to submit mail.  Since this is inconsistent
> with similar checks elsewhere, I believe it is unintentional.

No. I am working on a quality implementation, and that takes more
time than 'code that works'. More patches are not needed.

BTW I realized that I swapped the semantics of smtpd_sender_login_maps
(a mapping from sender address to the login names that are allowed
to use that sender address) when we were discussing the postdrop
feature (a mapping from login name to the sender addresses that the
login name is allowed to use).

If we stick with that model, then I think that the feature should be
renamed to local_login_sender_maps.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
On 10/17/20 11:34 AM, Wietse Venema wrote:
> Demi M. Obenour:
>> Should I submit another patch?  In addition to adding
>> local_sender_login_maps, I have fixed what appeared to be a bug in
>> the current postdrop and sendmail commands: root and $mail_owner were
>> not automatically allowed to submit mail.  Since this is inconsistent
>> with similar checks elsewhere, I believe it is unintentional.
>
> No. I am working on a quality implementation, and that takes more
> time than 'code that works'. More patches are not needed.

Indeed it does.  If I may ask, is there any way I could have made my
patch better?  I would like to know so that I can write better code
in the future.

> BTW I realized that I swapped the semantics of smtpd_sender_login_maps
> (a mapping from sender address to the login names that are allowed
> to use that sender address) when we were discussing the postdrop
> feature (a mapping from login name to the sender addresses that the
> login name is allowed to use).
>
> If we stick with that model, then I think that the feature should be
> renamed to local_login_sender_maps.

I agree, although I wonder if it is better to be consistent and
change the semantics to match those of smtpd_sender_login_maps.
local_login_sender_maps was easier to implement and seemed more
intuitive, but it is less consistent than local_sender_login_maps,
which can in some cases be set as

local_sender_login_maps = $smtpd_sender_login_maps

in main.cf.

> Wietse

Demi

OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
Demi M. Obenour:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.

> On 10/17/20 11:34 AM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> Should I submit another patch?  In addition to adding
> >> local_sender_login_maps, I have fixed what appeared to be a bug in
> >> the current postdrop and sendmail commands: root and $mail_owner were
> >> not automatically allowed to submit mail.  Since this is inconsistent
> >> with similar checks elsewhere, I believe it is unintentional.
> >
> > No. I am working on a quality implementation, and that takes more
> > time than 'code that works'. More patches are not needed.
>
> Indeed it does.  If I may ask, is there any way I could have made my
> patch better?  I would like to know so that I can write better code
> in the future.

Mudge (member of the former L0pht group) said that he trusted my
code becauuse it was dumb (he may have used a different word such
as 'brain-dead', it is a while ago).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
In reply to this post by Demi M. Obenour
Demi M. Obenour:

> > BTW I realized that I swapped the semantics of smtpd_sender_login_maps
> > (a mapping from sender address to the login names that are allowed
> > to use that sender address) when we were discussing the postdrop
> > feature (a mapping from login name to the sender addresses that the
> > login name is allowed to use).
> >
> > If we stick with that model, then I think that the feature should be
> > renamed to local_login_sender_maps.
>
> I agree, although I wonder if it is better to be consistent and
> change the semantics to match those of smtpd_sender_login_maps.
> local_login_sender_maps was easier to implement and seemed more
> intuitive, but it is less consistent than local_sender_login_maps,
> which can in some cases be set as
>
> local_sender_login_maps = $smtpd_sender_login_maps

This is not obviously right. In fact, I could argue for the opposite:

    local_login_sender_maps = $smtpd_login_sender_maps

smtpd_sender_login_maps pre-dates the Postfix submission services
(submission + smtps) by three years. It solved a problem for an
SMTP server that receives authenticated and unauthenticated messages
on the same port. In that setting, the sender address had to be the
search key for policy lookup.

In contrast, postdrop always knows a user ID; there is no legitimate
way to invoke postdrop anonymously. With the Postfix submission
services, SMTP submission has become more similar to postdrop
submission: Postfix always knows a user identity, thus the user
identity can become the search key for policy lookup. For the port
25 MTA-to-MTA service one can then reject all mail from a remote
site that claims to be from a local user.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Jaroslaw Rafa
Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze:
> For the port
> 25 MTA-to-MTA service one can then reject all mail from a remote
> site that claims to be from a local user.

That's not a good idea. Assume domain.com is configured that way and some
user on a completely different domain ([hidden email]) forwards their mail
to [hidden email]. Then what happens if some [hidden email] sends
mail to [hidden email] ?

One large email provider in Poland was once configured that way (or maybe
still is?). That provider was domain.com from this example, and I was
at that time administering a mail server at a university that was site.net
from this example. Many people forwarded their university email to private
email acccounts, some of them being at domain.com. This caused a lot of
trouble for us.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
Jaroslaw Rafa:
> Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze:
> > For the port
> > 25 MTA-to-MTA service one can then reject all mail from a remote
> > site that claims to be from a local user.
>
> That's not a good idea. Assume domain.com is configured that way and some
> user on a completely different domain ([hidden email]) forwards their mail
> to [hidden email]. Then what happens if some [hidden email] sends
> mail to [hidden email] ?

[historical scenario omitted]

Exactly the scanario that SPF and the like are supposed to prevent.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
On 10/17/20 6:42 PM, Wietse Venema wrote:

> Jaroslaw Rafa:
>> Dnia 17.10.2020 o godz. 18:25:13 Wietse Venema pisze:
>>> For the port
>>> 25 MTA-to-MTA service one can then reject all mail from a remote
>>> site that claims to be from a local user.
>>
>> That's not a good idea. Assume domain.com is configured that way and some
>> user on a completely different domain ([hidden email]) forwards their mail
>> to [hidden email]. Then what happens if some [hidden email] sends
>> mail to [hidden email] ?
>
> [historical scenario omitted]
>
> Exactly the scanario that SPF and the like are supposed to prevent.
>
> Wietse
To elaborate, my understanding is that site.net should use
MAIL FROM:<[hidden email]>, but leave the body unchanged.  domain.com
will then accept the message, as it is from an IP in site.net's SPF
record, and DKIM ignores the envelope.

Demi

OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Demi M. Obenour
In reply to this post by Wietse Venema
On 10/17/20 6:25 PM, Wietse Venema wrote:

> Demi M. Obenour:
>>> BTW I realized that I swapped the semantics of smtpd_sender_login_maps
>>> (a mapping from sender address to the login names that are allowed
>>> to use that sender address) when we were discussing the postdrop
>>> feature (a mapping from login name to the sender addresses that the
>>> login name is allowed to use).
>>>
>>> If we stick with that model, then I think that the feature should be
>>> renamed to local_login_sender_maps.
>>
>> I agree, although I wonder if it is better to be consistent and
>> change the semantics to match those of smtpd_sender_login_maps.
>> local_login_sender_maps was easier to implement and seemed more
>> intuitive, but it is less consistent than local_sender_login_maps,
>> which can in some cases be set as
>>
>> local_sender_login_maps = $smtpd_sender_login_maps
>
> This is not obviously right. In fact, I could argue for the opposite:
>
>     local_login_sender_maps = $smtpd_login_sender_maps
>
> smtpd_sender_login_maps pre-dates the Postfix submission services
> (submission + smtps) by three years. It solved a problem for an
> SMTP server that receives authenticated and unauthenticated messages
> on the same port. In that setting, the sender address had to be the
> search key for policy lookup.
>
> In contrast, postdrop always knows a user ID; there is no legitimate
> way to invoke postdrop anonymously. With the Postfix submission
> services, SMTP submission has become more similar to postdrop
> submission: Postfix always knows a user identity, thus the user
> identity can become the search key for policy lookup. For the port
> 25 MTA-to-MTA service one can then reject all mail from a remote
> site that claims to be from a local user.
>
> Wietse
I agree.  local_login_sender_maps is far, *far* more intuitive.  In my
test instance (which uses my own patch, pending the incorporation of
this into a release), I use the equivalent of the following:

main.cf:

local_login_sender_maps = pcre:/etc/postfix/senders

/etc/postfix/senders:

/^([A-Za-z_][A-Za-z0-9_.-]*)$/ $1, $1@localhost

Demi

OpenPGP_0xB288B55FFF9C22C1.asc (3K) Download Attachment
OpenPGP_signature (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Nick Tait
In reply to this post by Demi M. Obenour
On 18/10/20 11:54 am, Demi M. Obenour wrote:

> To elaborate, my understanding is that site.net should use
> MAIL FROM:<[hidden email]>, but leave the body unchanged.  domain.com
> will then accept the message, as it is from an IP in site.net's SPF
> record, and DKIM ignores the envelope.
>
> Demi

Don't forget that in doing this site.net will also be expected to handle
bounce notifications, and then forward them back to the original from
address. :-)

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
In reply to this post by Demi M. Obenour
postfix-3.6-20201025 has a preliminary implementation to limit the
envelope senders that a local user may specify to the Postfix
sendmail (or postdrop) command. The real work is done in a library
module, so that similar functionality can later be added to the
Postfix SMTP daemon.

Source:
http://ftp.porcupine.org/mirrors/postfix-release/index.html

Manual:
http://www.porcupine.org/postfix-mirror/postconf.5.html#local_login_sender_maps

I still need to add some credits to the HISTORY file, and update
the RELEASE_NOTES file with a feature summary.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Viktor Dukhovni
On Sun, Oct 25, 2020 at 02:46:26PM -0400, Wietse Venema wrote:

> postfix-3.6-20201025 has a preliminary implementation to limit the
> envelope senders that a local user may specify to the Postfix
> sendmail (or postdrop) command. The real work is done in a library
> module, so that similar functionality can later be added to the
> Postfix SMTP daemon.

Nice!  A nit correction and a question:

- Typo: in example:

--- proto/postconf.proto
+++ proto/postconf.proto
@@ -17947,7 +17947,7 @@ address when the '@' and <i>domain</i> part match. </dd>
 <pre>
 /etc/postfix/login_senders:
    # Allow both the bare username and the user@domain forms.
-    /(.+)/ $1 $[hidden email]/
+    /(.+)/ $1 $[hidden email]
 </pre>
 
 <p> This feature is available in Postfix 3.6 and later. </p>

- Question, with "#" as the prefix for numeric uids, how is one supposed
  to create indexed tables with these as lookup keys?  The below looks
  like a comment to me:

    #12345  [hidden email]

--
    VIktor.
Reply | Threaded
Open this post in threaded view
|

Re: Accessing the sending user from a canonical(5) table

Wietse Venema
Viktor Dukhovni:

> On Sun, Oct 25, 2020 at 02:46:26PM -0400, Wietse Venema wrote:
>
> > postfix-3.6-20201025 has a preliminary implementation to limit the
> > envelope senders that a local user may specify to the Postfix
> > sendmail (or postdrop) command. The real work is done in a library
> > module, so that similar functionality can later be added to the
> > Postfix SMTP daemon.
>
> Nice!  A nit correction and a question:
>
> - Typo: in example:
>
> --- proto/postconf.proto
> +++ proto/postconf.proto
> @@ -17947,7 +17947,7 @@ address when the '@' and <i>domain</i> part match. </dd>
>  <pre>
>  /etc/postfix/login_senders:
>     # Allow both the bare username and the user@domain forms.
> -    /(.+)/ $1 $[hidden email]/
> +    /(.+)/ $1 $[hidden email]
>  </pre>

Ack.

>  <p> This feature is available in Postfix 3.6 and later. </p>
>
> - Question, with "#" as the prefix for numeric uids, how is one supposed
>   to create indexed tables with these as lookup keys?  The below looks
>   like a comment to me:
>
>     #12345  [hidden email]

Yes, this would limit the usability to PCRE, LDAP, *SQL.
Postmap does not expand \ddd octal sequences in its input.

What about making the '#' a suffix instead? That is still unlikely
to clash with existing user naming schemes. BTW I realize that there
is no unit test for numerical UIDs; that needs to be fixed, too.

        Wietse
123