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

Viktor Dukhovni
> On Oct 25, 2020, at 9:08 PM, Wietse Venema <[hidden email]> wrote:
>
> 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.

A suffix looks like a good solution to me.

--
        Viktor.

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/25/20 2:46 PM, 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.
>
> Source:
> http://ftp.porcupine.org/mirrors/postfix-release/index.html

I looked at the source code, and all I can say is: Wow.  Thank you,
Wietse!  Your implementation is indeed of very high quality.
Certainly better than mine!

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

Nit: Given the quoted localpart TODO, it might be a good idea to
suggest limiting the character set that will be matched.  On a system
I ran, I would use:

/etc/postfix/login_senders:
    # Allow both the bare username and user@domain forms.
    /([A-Za-z][A-Za-z0-9_-]*)$/iAE $1, $[hidden email]

but the regex will of course be system-dependent.  I say "might"
because one could reasonably argue that if a user is allowed to login
with a username containing a comma or space, something has already
gone wrong.

> I still need to add some credits to the HISTORY file, and update
> the RELEASE_NOTES file with a feature summary.
>
> 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
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:
> > On Oct 25, 2020, at 9:08 PM, Wietse Venema <[hidden email]> wrote:
> >
> > 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.
>
> A suffix looks like a good solution to me.

On second consideration, I think I'll go for "uid:".

        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:

> Nit: Given the quoted localpart TODO, it might be a good idea to
> suggest limiting the character set that will be matched.  On a system
> I ran, I would use:
>
> /etc/postfix/login_senders:
>     # Allow both the bare username and user@domain forms.
>     /([A-Za-z][A-Za-z0-9_-]*)$/iAE $1, $[hidden email]
>
> but the regex will of course be system-dependent.  I say "might"
> because one could reasonably argue that if a user is allowed to login
> with a username containing a comma or space, something has already
> gone wrong.

That requires that Postfix security or system secuity are compromised:
the user can manipulate the setgid postdrop process, or they modified
the system library, or they modified the passsword file. Postfix
does not have to defend against broken security assumptions or
against a hostile super-user.

        Wietse
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Wietse Venema
> On Oct 26, 2020, at 1:43 PM, Wietse Venema <[hidden email]> wrote:
>
>> A suffix looks like a good solution to me.
>
> On second consideration, I think I'll go for "uid:".

Yes, indeed ":" is the natural suffix, or prefix.  But, when
used as a suffix, postmap issues a warnings about needing
to run it as postalias on files that look like aliases(5)
files:

        $ cat /tmp/xyzzy
        12345:  [hidden email]
        $ postmap btree:/tmp/xyzzy
        postmap: warning: /tmp/xyzzy, line 1: record is in "key: value" format; is this an alias file?

And does not complain when the key is ":12345", so the prefix
form is likely better...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

Wietse Venema
Viktor Dukhovni:
> > On Oct 26, 2020, at 1:43 PM, Wietse Venema <[hidden email]> wrote:
> >
> >> A suffix looks like a good solution to me.
> >
> > On second consideration, I think I'll go for "uid:".

As in uid:123345.

        Wietsse
Reply | Threaded
Open this post in threaded view
|

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

John Stoffel-2
In reply to this post by Wietse Venema
>>>>> "Wietse" == Wietse Venema <[hidden email]> writes:

Wietse> Viktor Dukhovni:
>> > On Oct 25, 2020, at 9:08 PM, Wietse Venema <[hidden email]> wrote:
>> >
>> > 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.
>>
>> A suffix looks like a good solution to me.

Wietse> On second consideration, I think I'll go for "uid:".

Could someone have an email address of "uid:[hidden email]" down
the line?  
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
> On Oct 27, 2020, at 11:42 PM, John Stoffel <[hidden email]> wrote:
>
> Could someone have an email address of "uid:[hidden email]" down
> the line?

The lookup key is a login name, given the syntax of the passwd(5)
file, no ":" characters can appear in a login name.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

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

John Stoffel-2
>>>>> "Viktor" == Viktor Dukhovni <[hidden email]> writes:

>> On Oct 27, 2020, at 11:42 PM, John Stoffel <[hidden email]> wrote:
>>
>> Could someone have an email address of "uid:[hidden email]" down
>> the line?

Viktor> The lookup key is a login name, given the syntax of the passwd(5)
Viktor> file, no ":" characters can appear in a login name.

Ah, my mistake.  I was thinking the lookup was the LHS of the email
address.  
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 Viktor Dukhovni
Viktor Dukhovni:
> > On Oct 27, 2020, at 11:42 PM, John Stoffel <[hidden email]> wrote:
> >
> > Could someone have an email address of "uid:[hidden email]" down
> > the line?
>
> The lookup key is a login name, given the syntax of the passwd(5)
> file, no ":" characters can appear in a login name.

However, one goal was to also expose this functionality in the smtps
and submission services, where the login syntax is not constrained by
UNIX password-file rules.

The specific form "uid:[hidden email]" won't collide with
"uid:[0-9]+", but other forms could. Perhaps we should make the
prefix for numerical UIDs configurable.

        Wietse
Reply | Threaded
Open this post in threaded view
|

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

Daniele Nicolodi
On 28/10/2020 16:23, Wietse Venema wrote:

> Viktor Dukhovni:
>>> On Oct 27, 2020, at 11:42 PM, John Stoffel <[hidden email]> wrote:
>>>
>>> Could someone have an email address of "uid:[hidden email]" down
>>> the line?
>>
>> The lookup key is a login name, given the syntax of the passwd(5)
>> file, no ":" characters can appear in a login name.
>
> However, one goal was to also expose this functionality in the smtps
> and submission services, where the login syntax is not constrained by
> UNIX password-file rules.
>
> The specific form "uid:[hidden email]" won't collide with
> "uid:[0-9]+", but other forms could. Perhaps we should make the
> prefix for numerical UIDs configurable.

Maybe it is a dumb idea, but what about using a prefix character that is
guaranteed not to be part of either local user names or email addresses
local parts? I believe the @ character is forbidden in both (although it
may be a bit confusing).

Cheers,
Dan
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Wietse Venema
On Wed, Oct 28, 2020 at 11:23:42AM -0400, Wietse Venema wrote:

> > The lookup key is a login name, given the syntax of the passwd(5)
> > file, no ":" characters can appear in a login name.
>
> However, one goal was to also expose this functionality in the smtps
> and submission services, where the login syntax is not constrained by
> UNIX password-file rules.
>
> The specific form "uid:[hidden email]" won't collide with
> "uid:[0-9]+", but other forms could. Perhaps we should make the
> prefix for numerical UIDs configurable.

But with SASL logins there's no notion of a numeric uid, but if the
*same* table is to be used to filter both unix login names and SASL
login names, then perhaps collisions with a SASL user named "uid:12345"
are possible, but bordering on the absurd.

    https://xkcd.com/327/

I don't think the flexibility is warranted, it just complicates
documentation and giving users actionable advice on list.

And in fact overloading SASL login == Unix login is already fraught with
potential conflicts, the namespaces are not necessarily the same.  If
anything that's the more likely problem than SASL logins of the
"uid:..." form.

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

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

Jaroslaw Rafa
In reply to this post by John Stoffel-2
Dnia 27.10.2020 o godz. 21:42:24 John Stoffel pisze:
> Could someone have an email address of "uid:[hidden email]" down
> the line?  

Localpart of the email address may be unquoted or may be enclosed in
quotation marks.

If unquoted, it may use any of these ASCII characters:

* uppercase and lowercase Latin letters A to Z and a to z
* digits 0 to 9
* printable characters !#$%&'*+-/=?^_`{|}~
* dot ., provided that it is not the first or last character and provided
  also that it does not appear consecutively (e.g., [hidden email]
  is not allowed).

* space and special characters "(),:;<>@[\] are allowed with restrictions
  (they are only allowed inside a quoted string, and in addition, a
  backslash or double-quote must be preceded by a backslash);
* comments are allowed with parentheses at either end of the local-part;
  e.g., john.smith(comment)@example.com and (comment)[hidden email]
  are both equivalent to [hidden email].

So, the email address

uid:[hidden email]

is invalid. However, this address is valid:

"uid:john"@some.place.home

but it doesnt have the string uid: at the beginning, so there's no
confusion.
--
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."
123