Dnia 27.10.2020 o godz. 21:42:24 John Stoffel pisze:
> Could someone have an email address of "uid:j...@some.place.home" 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
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 th
On 28/10/2020 16:23, Wietse Venema wrote:
> Viktor Dukhovni:
>>> On Oct 27, 2020, at 11:42 PM, John Stoffel wrote:
>>>
>>> Could someone have an email address of "uid:j...@some.place.home" down
>>> the line?
>>
>> The lookup key is a login name, given the syntax of the passwd(5)
>> file, no ":" c
Viktor Dukhovni:
> > On Oct 27, 2020, at 11:42 PM, John Stoffel wrote:
> >
> > Could someone have an email address of "uid:j...@some.place.home" 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.
Howeve
> "Viktor" == Viktor Dukhovni writes:
>> On Oct 27, 2020, at 11:42 PM, John Stoffel wrote:
>>
>> Could someone have an email address of "uid:j...@some.place.home" down
>> the line?
Viktor> The lookup key is a login name, given the syntax of the passwd(5)
Viktor> file, no ":" characters ca
> On Oct 27, 2020, at 11:42 PM, John Stoffel wrote:
>
> Could someone have an email address of "uid:j...@some.place.home" 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.
> "Wietse" == Wietse Venema writes:
Wietse> Viktor Dukhovni:
>> > On Oct 25, 2020, at 9:08 PM, Wietse Venema 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
Viktor Dukhovni:
> > On Oct 26, 2020, at 1:43 PM, Wietse Venema 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
> On Oct 26, 2020, at 1:43 PM, Wietse Venema 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 postal
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_-
Viktor Dukhovni:
> > On Oct 25, 2020, at 9:08 PM, Wietse Venema 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 su
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 ad
> On Oct 25, 2020, at 9:08 PM, Wietse Venema 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
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
> > mo
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 functio
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://ft
On 18/10/20 11:54 am, Demi M. Obenour wrote:
To elaborate, my understanding is that site.net should use
MAIL FROM:, 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 do
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
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
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 compl
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 (us...
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
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
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 submi
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 simila
> On Oct 17, 2020, at 2:55 AM, Demi M. Obenour 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.
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 belie
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
>> defau
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 go
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 w
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
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 passw
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
Demi M. Obenour:
> On 10/6/20 12:46 PM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> On 10/6/20 9:47 AM, Wietse Venema wrote:
> >>> allow 'not found' users, similar to smtpd_sender_login_maps
> >>
> >> Would it be possible to make this configurable? The documentation
> >> seems to imply that rej
On 10/6/20 12:46 PM, Wietse Venema wrote:
Demi M. Obenour:
On 10/6/20 9:47 AM, Wietse Venema wrote:
allow 'not found' users, similar to smtpd_sender_login_maps
Would it be possible to make this configurable? The documentation
seems to imply that reject_sender_login_mismatch considers ?not
fo
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 10/6/20 9:47 AM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> Patch (made against 3.5.7) attached. I lightly tested it locally and
> >> it seems to work, but there could very well be bugs. I am vi
On 10/6/20 9:47 AM, Wietse Venema wrote:
Demi M. Obenour:
Patch (made against 3.5.7) attached. I lightly tested it locally and
it seems to work, but there could very well be bugs. I am virtually
certain that I violated the Postfix coding style somewhere, sorry.
I can also send the patch inline
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 10/5/20 6:15 PM, Wietse Venema wrote:
> > Demi M. Obenour:
> >> There was a recent vulnerability in OpenBSD due to libc malfunctioning
> >> in a set-uid-root program under very low resource limits. I
On 10/5/20 6:15 PM, Wietse Venema wrote:
Demi M. Obenour:
There was a recent vulnerability in OpenBSD due to libc malfunctioning
in a set-uid-root program under very low resource limits. I would
prefer to minimize the amount of third-party libraries that are used
by postdrop. That said, anothe
Demi M. Obenour:
> There was a recent vulnerability in OpenBSD due to libc malfunctioning
> in a set-uid-root program under very low resource limits. I would
> prefer to minimize the amount of third-party libraries that are used
> by postdrop. That said, another option would be to error out if th
On 10/5/20 10:51 AM, Wietse Venema wrote:
Demi M. Obenour:
On 2020-10-04 19:55, Wietse Venema wrote:
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
On 2020-09-30 16:35, Wietse Venema wrote:
Demi M. Obenour:
- If a message arrives via the SMTPS o
Demi M. Obenour:
> On 2020-10-04 19:55, Wietse Venema wrote:
> > Demi M. Obenour:
> >
> > Checking application/pgp-signature: FAILURE
> > -- Start of PGP signed section.
> >> On 2020-09-30 16:35, Wietse Venema wrote:
> >>> Demi M. Obenour:
> - If a message arrives via the SMTPS or submission
On 2020-10-04 19:55, Wietse Venema wrote:
> Demi M. Obenour:
>
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
>> On 2020-09-30 16:35, Wietse Venema wrote:
>>> Demi M. Obenour:
- If a message arrives via the SMTPS or submission ports, I
want to replace t
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 2020-09-30 16:35, Wietse Venema wrote:
> > Demi M. Obenour:
> >> - If a message arrives via the SMTPS or submission ports, I
> >> want to replace the address part of the user-supplied From:
> >> h
On 2020-09-30 16:35, Wietse Venema wrote:
> Demi M. Obenour:
>> - If a message arrives via the SMTPS or submission ports, I
>> want to replace the address part of the user-supplied From:
>> header with the envelope From: header. This allows me to use
>> reject-sender-login-mismatch to preven
Jaroslaw Rafa:
> X-Authentication-Warning: : set sender to
> using -f
If you're willing to parse headers, then all the information that
you need is already available. There is no need to add yet another
header with that stuff.
- You already have the numerical UID in the existing Received:
hea
On 2020-09-30 20:32, Jaroslaw Rafa wrote:
> Dnia 30.09.2020 o godz. 16:35:37 Wietse Venema pisze:
>>With authenticated smtp submission, the envelope.from can be
>>constrained by smtpd_sender_login_maps.
>>
>>With sendmail/postdrop submission the UNIX login name can be
>>overidden wi
Dnia 30.09.2020 o godz. 16:35:37 Wietse Venema pisze:
>With authenticated smtp submission, the envelope.from can be
>constrained by smtpd_sender_login_maps.
>
>With sendmail/postdrop submission the UNIX login name can be
>overidden with "sendmail -f". There is no code in Postfix to
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> On 2020-09-30 10:08, Wietse Venema wrote:
> > Demi M. Obenour:
> >
> > Checking application/pgp-signature: FAILURE
> >> When a message is submitted using postdrop, Postfix is obviously aware
> >> of whi
On 2020-09-30 12:18, @lbutlr wrote:
> On 30 Sep 2020, at 10:04, Demi M. Obenour wrote:
>> while www-data can only send mail as majordomo,
>
> That will simply brea mailing list. Look at the headers from this message,
> for example. Your policy on the postfox.org server would screw up this list.
On 2020-09-30 10:08, Wietse Venema wrote:
> Demi M. Obenour:
>
> Checking application/pgp-signature: FAILURE
>> When a message is submitted using postdrop, Postfix is obviously aware
>> of which user submitted it, as it includes the UID in the Received:
>> header. Is it possible to use this infor
Demi M. Obenour:
Checking application/pgp-signature: FAILURE
> When a message is submitted using postdrop, Postfix is obviously aware
> of which user submitted it, as it includes the UID in the Received:
> header. Is it possible to use this information in a canonical(5)
> table, or is a milter re
When a message is submitted using postdrop, Postfix is obviously aware
of which user submitted it, as it includes the UID in the Received:
header. Is it possible to use this information in a canonical(5)
table, or is a milter required?
Thank you,
Demi
signature.asc
Description: OpenPGP digita
53 matches
Mail list logo
