[pfx] Re: dnsbl submissions

[Allen Coates via Postfix-users]

On 07/07/2024 05:18, Nick Edwards via Postfix-users wrote:
>
> Main:
> submission_recipient_restrictions =
>         reject_rbl_client cbl.abuseat.org 
> =127.0.0.[2..255]
>         reject_unknown_sender_domain
>         reject_unknown_recipient_domain
>         permit_mynetworks
>         permit_sasl_authenticated
>         reject
>

Did you remember to include a "smtpd_restriction_classes"  directive?  the only 
thing I can think of  :-)

Allen C
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Documentation Prefix

[Allen Coates via Postfix-users]

I have just been perusing my firewall logs, and notice I have had several 
"hits" using the documentation prefix
(2001:db8::/32) as the source address.   Eleven in a fortnight or so.

I have also had some hits (on my website) from  Teredo addresses.  I am 
allowing these, because (arguably) we are still
transitioning to IPv6.

The price of freedom is eternal vigilance.

Allen C


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[Cody Millard via Postfix-users]

As of the first week of 2021, the Composite Blocklist (CBL) is being 
retired. This data, however, is included in the eXploits Blocklist 
(XBL). We advise any users currently accessing the CBL through 
cbl.abuseat.org to reconfigure and query xbl.spamhaus.org.


https://www.spamhaus.org/resource-hub/dnsbl/update-for-composite-blocklist-cbl-users/

Might change the RBL that is being used as cbl.abuseat.org was retired 
in 2021.




Every main.cf config I've seen uses commas. Ive added them to your quote 
below.


On 7/6/2024 11:18 PM, Nick Edwards via Postfix-users wrote:

Main:
submission_recipient_restrictions =
        reject_rbl_client cbl.abuseat.org 
=127.0.0.[2..255],

        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        permit_sasl_authenticated,
        reject



Is _submission__recipient_restrictions a real config parameter? 
Shouldn't it be _smtpd__recipient_restrictions?
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[John Fawcett via Postfix-users]

On 07/07/2024 06:18, Nick Edwards via Postfix-users wrote:

Howdy,

I've never seen the point in this before, but i've been asked by a 
client to implement it if possible, that is, place dnsbl checks on 
submission and smtps connections, I've tried a few combinations but it 
does not seem to be working, no doubt someone can see the error and 
slap me a new one for overlooking the obvious on a Sunday.


Master:
smtps     inet  n       -       n       -       - smtpd
  -o smtpd_client_restrictions=$submission_client_restrictions
  -o smtpd_recipient_restrictions=$submission_recipient_restrictions
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o receive_override_options=no_header_body_checks
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_data_restrictions=
  -o smtpd_client_connection_rate_limit=1000
  -o content_filter=

submission inet n       -       n       -       - smtpd
  -o smtpd_client_restrictions=$submission_client_restrictions
  -o smtpd_recipient_restrictions=$submission_recipient_restrictions
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_data_restrictions=
  -o receive_override_options=no_header_body_checks
  -o mynetworks=127.0.0.0/8,[::1]/128 
  -o content_filter=
  -o smtpd_client_connection_rate_limit=1000
  -o anvil_rate_time_unit=3600

Main:
submission_recipient_restrictions =
        reject_rbl_client cbl.abuseat.org 
=127.0.0.[2..255]

        reject_unknown_sender_domain
        reject_unknown_recipient_domain
        permit_mynetworks
        permit_sasl_authenticated
        reject

I've tried reordering a few of these but no go, tcpdump does not show 
any attempts to the BL, the clients are definitely coming in on port 
587 and 465, we don't allow smtp auth on 25 (tested), and the 
smtpd_recipient_restrictions = contains same BL and


Open to suggestions,
Thanks
Nik


Hi Nik

people have posted some working configurations that are in the list 
archives so might be useful to look up.


But I can see some potential points to address. I would recommend adding 
-o smtpd_delay_reject=no to the master.cf configuration. Most people use 
the default yes, since it delays evaluating client/helo/sender 
restriction until the RCPT TO stage of the mail transaction and so 
rejects can log more info. Blocking submission like you're client wants 
will not work with smtpd_delay_reject = yes. You'll also need to put the 
rbl check in the smtpd_client_restrictions (so in 
submission_client_restrictions in your case). With those two 
modification the evaluation of the rbl disconnection will happen upon 
client connection.


I haven't personally used the $ syntax you're using so I can't say much 
about it, and the following comment may not be totally relevant, but 
just in case I'll mention that in my configuration I have no $ in front 
of my restriction classes. As mentioned by Allen in that case you'll 
need to use the smtpd_restriction_classes configuration to tell postfix 
which custom restriction classes you're defining.


John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[Victoriano Giralt via Postfix-users]

El dom, 07-07-2024 a las 12:51 +0200, John Fawcett via Postfix-users
escribió:
>  
> On 07/07/2024 06:18, Nick Edwards via Postfix-users wrote:
>   
> > Master:
> >  
> > smtps     inet  n       -       n       -       -       smtpd
> >    -o smtpd_client_restrictions=$submission_client_restrictions
> >    -o smtpd_recipient_restrictions=$submission_recipient_restrictions
> >    -o smtpd_tls_wrappermode=yes 
> >    -o smtpd_sasl_auth_enable=yes
> >    -o receive_override_options=no_header_body_checks
> >    -o smtpd_helo_restrictions=
> >    -o smtpd_sender_restrictions=
> >    -o smtpd_data_restrictions=
> >    -o smtpd_client_connection_rate_limit=1000
> >    -o content_filter=
> >  
> > submission inet n       -       n       -       -       smtpd
> >    -o smtpd_client_restrictions=$submission_client_restrictions
> >    -o smtpd_recipient_restrictions=$submission_recipient_restrictions
> >    -o smtpd_sasl_auth_enable=yes
> >    -o smtpd_helo_restrictions=
> >    -o smtpd_sender_restrictions=
> >    -o smtpd_data_restrictions=  
> >    -o receive_override_options=no_header_body_checks
> >    -o mynetworks=127.0.0.0/8,[::1]/128
> >    -o content_filter=
> >    -o smtpd_client_connection_rate_limit=1000
> >    -o anvil_rate_time_unit=3600
> >   
> > Main:
> >   
> > submission_recipient_restrictions =
> >          reject_rbl_client cbl.abuseat.org=127.0.0.[2..255] 
> >          reject_unknown_sender_domain
> >          reject_unknown_recipient_domain
> >          permit_mynetworks
> >          permit_sasl_authenticated
> >          reject
> >  
> You'll also need to put the rbl check in the smtpd_client_restrictions
> (so in submission_client_restrictions in your case). With those two
> modification the evaluation of the rbl disconnection will happen upon
> client connection.

Agreed on this one.

> I haven't personally used the $ syntax you're using so I can't say much
> about it, and the following comment may not be totally relevant, but just
> in case I'll mention that in my configuration I have no $ in front of my
> restriction classes. As mentioned by Allen in that case you'll need to
> use the smtpd_restriction_classes configuration to tell postfix which
> custom restriction classes you're defining.

The $ syntax is the right thing to do in order to keep different
restrictions for different services in main.cf and reference them in the
corresponding service in master.cf as Nik has done.


-- 
Victoriano Giralt   Head of Systems Administration Service
Central ICT ServicesUniversity of Malaga
+34952131415SPAIN
==
Note: signature.asc is the electronic signature of present message
A: Yes.
> Q: Are you sure ?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email ?



signature.asc
Description: This is a digitally signed message part
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[John Fawcett via Postfix-users]

On 07/07/2024 13:09, Victoriano Giralt via Postfix-users wrote:

El dom, 07-07-2024 a las 12:51 +0200, John Fawcett via Postfix-users
escribió:
  
On 07/07/2024 06:18, Nick Edwards via Postfix-users wrote:
   
... 
I haven't personally used the $ syntax you're using so I can't say much

about it, and the following comment may not be totally relevant, but just
in case I'll mention that in my configuration I have no $ in front of my
restriction classes. As mentioned by Allen in that case you'll need to
use the smtpd_restriction_classes configuration to tell postfix which
custom restriction classes you're defining.

The $ syntax is the right thing to do in order to keep different
restrictions for different services in main.cf and reference them in the
corresponding service in master.cf as Nik has done.


Ok, I had suspected that it might be a valid alternative. However, the 
reason I mentioned it was because my configuration without $ seems to be 
working fine:


submission inet n  -   n   -   -   smtpd
    -o syslog_name=postfix/submission
    -o stress=
    -o smtpd_sasl_auth_enable=yes
    -o rbl_reply_maps=texthash:/etc/postfix/dnsbl_reply
    -o smtpd_delay_reject=no
    -o smtpd_etrn_restrictions=reject
    -o smtpd_helo_restrictions=
    -o smtpd_client_restrictions=submission_client_checks
    -o smtpd_sender_restrictions=submission_sender_checks
    -o smtpd_recipient_restrictions=submission_recipient_checks
    -o smtpd_relay_restrictions=submission_relay_checks
    -o smtpd_tls_security_level=encrypt
    -o content_filter=smtp-amavis:[127.0.0.1]:10026
    -o cleanup_service_name=ascleanup

John
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[Nick Edwards via Postfix-users]

Thanks John! You nailed it, made the two changes you suggested, and it is
now blocking, client will be happy,

On Sun, Jul 7, 2024 at 8:52 PM John Fawcett via Postfix-users <
postfix-users@postfix.org> wrote:

> On 07/07/2024 06:18, Nick Edwards via Postfix-users wrote:
>
> Howdy,
>
> I've never seen the point in this before, but i've been asked by a client
> to implement it if possible, that is, place dnsbl checks on submission and
> smtps connections, I've tried a few combinations but it does not seem to be
> working, no doubt someone can see the error and slap me a new one for
> overlooking the obvious on a Sunday.
>
> Master:
> smtps inet  n   -   n   -   -   smtpd
>   -o smtpd_client_restrictions=$submission_client_restrictions
>   -o smtpd_recipient_restrictions=$submission_recipient_restrictions
>   -o smtpd_tls_wrappermode=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o receive_override_options=no_header_body_checks
>   -o smtpd_helo_restrictions=
>   -o smtpd_sender_restrictions=
>   -o smtpd_data_restrictions=
>   -o smtpd_client_connection_rate_limit=1000
>   -o content_filter=
>
> submission inet n   -   n   -   -   smtpd
>   -o smtpd_client_restrictions=$submission_client_restrictions
>   -o smtpd_recipient_restrictions=$submission_recipient_restrictions
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_helo_restrictions=
>   -o smtpd_sender_restrictions=
>   -o smtpd_data_restrictions=
>   -o receive_override_options=no_header_body_checks
>   -o mynetworks=127.0.0.0/8,[::1]/128 
>   -o content_filter=
>   -o smtpd_client_connection_rate_limit=1000
>   -o anvil_rate_time_unit=3600
>
> Main:
> submission_recipient_restrictions =
> reject_rbl_client cbl.abuseat.org=127.0.0.[2..255]
> reject_unknown_sender_domain
> reject_unknown_recipient_domain
> permit_mynetworks
> permit_sasl_authenticated
> reject
>
> I've tried reordering a few of these but no go, tcpdump does not show any
> attempts to the BL, the clients are definitely coming in on port 587 and
> 465, we don't allow smtp auth on 25 (tested), and the
> smtpd_recipient_restrictions = contains same BL and
>
> Open to suggestions,
> Thanks
> Nik
>
> Hi Nik
>
> people have posted some working configurations that are in the list
> archives so might be useful to look up.
>
> But I can see some potential points to address. I would recommend adding
> -o smtpd_delay_reject=no to the master.cf configuration. Most people use
> the default yes, since it delays evaluating client/helo/sender restriction
> until the RCPT TO stage of the mail transaction and so rejects can log more
> info. Blocking submission like you're client wants will not work with
> smtpd_delay_reject = yes. You'll also need to put the rbl check in the
> smtpd_client_restrictions (so in submission_client_restrictions in your
> case). With those two modification the evaluation of the rbl disconnection
> will happen upon client connection.
>
> I haven't personally used the $ syntax you're using so I can't say much
> about it, and the following comment may not be totally relevant, but just
> in case I'll mention that in my configuration I have no $ in front of my
> restriction classes. As mentioned by Allen in that case you'll need to use
> the smtpd_restriction_classes configuration to tell postfix which custom
> restriction classes you're defining.
> John
>
>
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[Nick Edwards via Postfix-users]

Thanks Cody,  made that change too.

On Sun, Jul 7, 2024 at 8:25 PM Cody Millard via Postfix-users <
postfix-users@postfix.org> wrote:

> As of the first week of 2021, the Composite Blocklist (CBL) is being
> retired. This data, however, is included in the eXploits Blocklist (XBL).
> We advise any users currently accessing the CBL through cbl.abuseat.org
> to reconfigure and query xbl.spamhaus.org.
>
>
> https://www.spamhaus.org/resource-hub/dnsbl/update-for-composite-blocklist-cbl-users/
>
> Might change the RBL that is being used as cbl.abuseat.org was retired in
> 2021.
>
>
>
> Every main.cf config I've seen uses commas. Ive added them to your quote
> below.
>
> On 7/6/2024 11:18 PM, Nick Edwards via Postfix-users wrote:
>
> Main:
> submission_recipient_restrictions =
> reject_rbl_client cbl.abuseat.org=127.0.0.[2..255],
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> permit_mynetworks,
> permit_sasl_authenticated,
> reject
>
>
> Is *submission*_recipient_restrictions a real config parameter? Shouldn't
> it be *smtpd*_recipient_restrictions?
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: dnsbl submissions

[Viktor Dukhovni via Postfix-users]

On Sun, Jul 07, 2024 at 01:50:19PM +0200, John Fawcett via Postfix-users wrote:

> Ok, I had suspected that it might be a valid alternative. However, the
> reason I mentioned it was because my configuration without $ seems to be
> working fine:
> 
> submission inet n  -   n   -   -   smtpd
>     -o smtpd_client_restrictions=submission_client_checks
>     -o smtpd_sender_restrictions=submission_sender_checks
>     -o smtpd_recipient_restrictions=submission_recipient_checks
>     -o smtpd_relay_restrictions=submission_relay_checks

Sorry, no, this generally will not work, unless you also list these as
elements of "smtpd_restriction_classes", but simpler to just prefix with
"$" as suggested upthread.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Documentation Prefix

[Ralph Seichter via Postfix-users]

* Allen Coates via Postfix-users:

> I have just been perusing my firewall logs, and notice I have had
> several "hits" using the documentation prefix (2001:db8::/32) as the
> source address. [...]
>
> I have also had some hits (on my website) from  Teredo addresses.  I
> am allowing these, because (arguably) we are still transitioning to
> IPv6.

"Still transitioning", are we? ;-) RFC 3849 is 20 years (!) old, almost
to the day, and https://www.rfc-editor.org/rfc/rfc3849.html#section-3 is
pretty clear:

  This assignment implies that IPv6 network operators should add this
  address prefix to the list of non-routeable IPv6 address space, and
  if packet filters are deployed, then this address prefix should be
  added to packet filters.

Anybody using 2001:db8::/32 to connect over the internet is simply doing
it wrong, and I don't think that attempts at enabling their erroneous
efforts is helpful.

-Ralph
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Does unix:passwd.byname do anything in local_recipient_maps on MacOS?

[Robert Fuhrer via Postfix-users]

Hi,

I'm running PostFix 3.2.2 on Mac OS Sonoma, configured to accept local delivery 
for a single local login user, i.e. a user that actually has an account on the 
Mac.

To that end, I have the following in main.cf:

 local_recipient_maps = proxy:unix:passwd.byname $alias_maps

This has worked fine AFAICT for some years.

However, as I understand it, MacOS uses Open Directory to manage normal users' 
login info. As a result, there are no entries for normal users in /etc/passwd.

Does the "passwd" accessor in PostFix talk to Open Directory on MacOS, or is 
the above use of "unix:passwd.byname" effectively a no-op?

In that case, perhaps the reason my setup works is that I've also added said 
user to the "/etc/postfix/access" DB?

Cheers,
- Bob Fuhrer
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Local delivery for both login and virtual users in a single domain?

[Robert Fuhrer via Postfix-users]

Hi,

I've got a Mac running PostFix 3.2.2, configured for local delivery for a 
single domain, call it "mydomain.net ", using dovecot's 
local delivery agent.

At the moment, there's just one relevant login user on the server, for which 
I've got PostFix delivering emails addressed to "myu...@mydomain.net 
" to that user's Maildir store. This has worked 
fine, for years.

As such, here are the relevant bits of config:

 # main.cf
 myhostname = mail.mydomain.net 
 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
 local_recipient_maps = proxy:unix:passwd.byname $alias_maps
 alias_database = hash:/etc/aliases

 # access
 myu...@mydomain.net   OK

 # virtual
 myu...@mydomain.net  myuser@localhost

(I'm actually not sure the virtual user entry is actually necessary. I suspect 
not. Is it?)

I'd like to augment this PostFix setup to accept local delivery for a very 
limited number (say, 3-5) of specific NON-login users in the same domain, e.g. 
"otheru...@mydomain.net ", also via Maildir. (I 
already have those users' mailboxes set up in Dovecot, so I can see their 
mailboxes and emails via the Dovecot IMAP service in my mail client.)

I understand that one shouldn't also list "@mydomain.net" as a 
virtual_mailbox_domain (since it's already $mydestination), so what should I do?

I'm tempted to try this:
1) Set up a fake virtual domain, say, "mydomain.virtual", just to map those 
non-login users' addresses from the external addresses (@mydomain.net).
2) Add a virtual mailbox domain for that domain.
3) Set up local delivery for the users in that domain (by mapping them to 
otheruser@localhost?).

or something like that.

Any advice on how to set this up properly?

Thanks in advance,
- Bob Fuhrer
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Does unix:passwd.byname do anything in local_recipient_maps on MacOS?

[John Fawcett via Postfix-users]

On 07/07/2024 18:57, Robert Fuhrer via Postfix-users wrote:

Hi,

I'm running PostFix 3.2.2 on Mac OS Sonoma, configured to accept local delivery 
for a single local login user, i.e. a user that actually has an account on the 
Mac.

To that end, I have the following in main.cf:

  local_recipient_maps = proxy:unix:passwd.byname $alias_maps

This has worked fine AFAICT for some years.

However, as I understand it, MacOS uses Open Directory to manage normal users' 
login info. As a result, there are no entries for normal users in /etc/passwd.

Does the "passwd" accessor in PostFix talk to Open Directory on MacOS, or is the above 
use of "unix:passwd.byname" effectively a no-op?

In that case, perhaps the reason my setup works is that I've also added said user to the 
"/etc/postfix/access" DB?

Cheers,
- Bob Fuhrer
___


Hi Bob

Postfix makes a call to getpwnam() from the standard libc library. How 
that is implemented is OS dependent. On MacOS it may be reading a 
different file to /etc/passwd.


You could check what is being returned by running a query with postmap 
where xx is the system username without the domain.


postmap -q xx unix:passwd.byname

John

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Local delivery for both login and virtual users in a single domain?

[John Fawcett via Postfix-users]

On 07/07/2024 18:59, Robert Fuhrer via Postfix-users wrote:

Hi,

I've got a Mac running PostFix 3.2.2, configured for local delivery 
for a single domain, call it "mydomain.net ", 
using dovecot's local delivery agent.


At the moment, there's just one relevant login user on the server, for 
which I've got PostFix delivering emails addressed to 
"myu...@mydomain.net" to that user's Maildir store. This has worked 
fine, for years.


As such, here are the relevant bits of config:

 # main.cf
 myhostname = mail.mydomain.net 
 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
 local_recipient_maps = proxy:unix:passwd.byname $alias_maps
 alias_database = hash:/etc/aliases

 # access
myu...@mydomain.net  OK

 # virtual
myu...@mydomain.net myuser@localhost

(I'm actually not sure the virtual user entry is actually necessary. I 
suspect not. Is it?)


I'd like to augment this PostFix setup to accept local delivery for a 
very limited number (say, 3-5) of specific NON-login users in the same 
domain, e.g. "otheru...@mydomain.net", also via Maildir. (I already 
have those users' mailboxes set up in Dovecot, so I can see their 
mailboxes and emails via the Dovecot IMAP service in my mail client.)


I understand that one shouldn't also list "@mydomain.net" as a 
virtual_mailbox_domain (since it's already $mydestination), so what 
should I do?


I'm tempted to try this:
1) Set up a fake virtual domain, say, "mydomain.virtual", just to map 
those non-login users' addresses from the external addresses 
(@mydomain.net).

2) Add a virtual mailbox domain for that domain.
3) Set up local delivery for the users in that domain (by mapping them 
to otheruser@localhost?).


or something like that.

Any advice on how to set this up properly?

Thanks in advance,
- Bob Fuhrer


Hi Bob

if email is being delivered to dovecot for the current single user and 
the same should be done for the other users, I would just list them as 
local recipients. You could just add an additional map file to 
local_recipient_maps listing these users. You could even drop the 
unix:passwd.byname lookup if you also list your existing user in that 
map. What type of user database you are using in Dovecot?


John
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Documentation Prefix

[Allen Coates via Postfix-users]

On 07/07/2024 16:13, Ralph Seichter via Postfix-users wrote:
> * Allen Coates via Postfix-users:
>
>> I have just been perusing my firewall logs, and notice I have had
>> several "hits" using the documentation prefix (2001:db8::/32) as the
>> source address. [...]
>>
>> I have also had some hits (on my website) from  Teredo addresses.  I
>> am allowing these, because (arguably) we are still transitioning to
>> IPv6.
> "Still transitioning", are we? ;-) RFC 3849 is 20 years (!) old, almost
> to the day, and https://www.rfc-editor.org/rfc/rfc3849.html#section-3 is
> pretty clear:
>
>   This assignment implies that IPv6 network operators should add this
>   address prefix to the list of non-routeable IPv6 address space, and
>   if packet filters are deployed, then this address prefix should be
>   added to packet filters.
>
> Anybody using 2001:db8::/32 to connect over the internet is simply doing
> it wrong, and I don't think that attempts at enabling their erroneous
> efforts is helpful.
>
> -Ralph

I am blocking  2001:db8::/32 (of course);  it's the Teredo prefix which I am 
allowing. 

Having been retired for 15 years, and only running a personal (domestic) 
server, it is difficult to judge how
commonplace these transition protocols still are.

Allen C
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Local delivery for both login and virtual users in a single domain?

[Robert Fuhrer via Postfix-users]

Oh, thanks; I should’ve realized I could just add another map to 
local_recipient_maps. D’oh!

My Dovecot setup uses MySQL to identify users+passwords.

I assume you’re asking that because (as I just discovered) PostFix nominally 
supports MySQL, but OTOH “postconf -m” doesn’t list the “mysql” lookup table 
type, so it’s not supported on the distribution that comes with MacOS.

That said, for the one login user, I had been specifying:

  # main.cf
  home_mailbox = Maildir/

but my Dovecot setup stores the base directory path in the MySQL DB. For 
non-login users, that base directory is of course not relative to the user's 
“home directory”, since non-login users have no “home directory”. (For login 
users, the base directory just happens to point to their home directory.)

I guess Dovecot’s LDA would consult the MySQL DB to find the user's Maildir, 
but perhaps PostFix’s invocation of the Dovecot LDA overrides the path using 
the “home_mailbox”. (?)

In that case, without virtual_mailbox_base, I don’t see how to point PostFix to 
the right Maildir for non-login users.

Thanks so much for the help!!

Cheers,
 - Bob

> On Jul 7, 2024, at 4:12 PM, John Fawcett via Postfix-users 
>  wrote:
> On 07/07/2024 18:59, Robert Fuhrer via Postfix-users wrote:
>> Hi,
>> 
>> I've got a Mac running PostFix 3.2.2, configured for local delivery for a 
>> single domain, call it "mydomain.net ", using 
>> dovecot's local delivery agent.
>> 
>> At the moment, there's just one relevant login user on the server, for which 
>> I've got PostFix delivering emails addressed to "myu...@mydomain.net 
>> " to that user's Maildir store. This has worked 
>> fine, for years.
>> 
>> As such, here are the relevant bits of config:
>> 
>>  # main.cf
>>  myhostname = mail.mydomain.net 
>>  mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
>>  local_recipient_maps = proxy:unix:passwd.byname $alias_maps
>>  alias_database = hash:/etc/aliases
>> 
>>  # access
>>  myu...@mydomain.net   OK
>> 
>>  # virtual
>>  myu...@mydomain.net  myuser@localhost
>> 
>> (I'm actually not sure the virtual user entry is actually necessary. I 
>> suspect not. Is it?)
>> 
>> I'd like to augment this PostFix setup to accept local delivery for a very 
>> limited number (say, 3-5) of specific NON-login users in the same domain, 
>> e.g. "otheru...@mydomain.net ", also via 
>> Maildir. (I already have those users' mailboxes set up in Dovecot, so I can 
>> see their mailboxes and emails via the Dovecot IMAP service in my mail 
>> client.)
>> 
>> I understand that one shouldn't also list "@mydomain.net" as a 
>> virtual_mailbox_domain (since it's already $mydestination), so what should I 
>> do?
>> 
>> I'm tempted to try this:
>> 1) Set up a fake virtual domain, say, "mydomain.virtual", just to map those 
>> non-login users' addresses from the external addresses (@mydomain.net).
>> 2) Add a virtual mailbox domain for that domain.
>> 3) Set up local delivery for the users in that domain (by mapping them to 
>> otheruser@localhost?).
>> 
>> or something like that.
>> 
>> Any advice on how to set this up properly?
>> 
>> Thanks in advance,
>> - Bob Fuhrer
>> 
> Hi Bob
> 
> if email is being delivered to dovecot for the current single user and the 
> same should be done for the other users, I would just list them as local 
> recipients. You could just add an additional map file to local_recipient_maps 
> listing these users. You could even drop the unix:passwd.byname lookup if you 
> also list your existing user in that map. What type of user database you are 
> using in Dovecot?
> 
> John
> 
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Local delivery for both login and virtual users in a single domain?

[John Fawcett via Postfix-users]

Hi Bob

yes, I was going to suggest then using mysql lookup maps in postfix to 
share the user database from dovecot. I imagine there is a way to build 
postfix with mysql support on MacOS but I don't know what it is.


If not you could still generate the info for one of the supported 
postfix map types from a mysql query that refreshs the map file 
periodically (being careful though to not do that on the live file 
directly, but a temporary file which is then renamed to the live file to 
avoid postfix reading incomplete files while they are being generated).


I switched from dovecot lda many years ago, so I can't remember exactly 
the configuration, but for sure it can deliver for any user if correctly 
configured as the delivery mechanism in postfix.


I use lmtp and have it like this:

mailbox_command =
home_mailbox =

mailbox_transport = lmtp:unix:private/dovecot-lmtp
(with lmtp service also configured on dovecot)

To keep with lda I think you can do it with this in master.cf, though I 
may not have remembered that 100% right.


dovecot   unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail:vmail 
argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}


and in main.cf

mailbox_transport=dovecot

dovecot_destination_recipient_limit = 1

mailbox_command =
home_mailbox =

Other setups are possible too, but hopefully this one is nearer to your 
current configuration.


John

On 08/07/2024 00:02, Robert Fuhrer via Postfix-users wrote:
Oh, thanks; I should’ve realized I could just add another map to 
local_recipient_maps. D’oh!


My Dovecot setup uses MySQL to identify users+passwords.

I assume you’re asking that because (as I just discovered) PostFix 
nominally supports MySQL, but OTOH “postconf -m” doesn’t list the 
“mysql” lookup table type, so it’s not supported on the distribution 
that comes with MacOS.


That said, for the one login user, I had been specifying:

  # main.cf
  home_mailbox = Maildir/

but my Dovecot setup stores the base directory path in the MySQL DB. 
For non-login users, that base directory is of course not relative to 
the user's “home directory”, since non-login users have no “home 
directory”. (For login users, the base directory just happens to point 
to their home directory.)


I guess Dovecot’s LDA would consult the MySQL DB to find the user's 
Maildir, but perhaps PostFix’s invocation of the Dovecot LDA overrides 
the path using the “home_mailbox”. (?)


In that case, without virtual_mailbox_base, I don’t see how to point 
PostFix to the right Maildir for non-login users.


Thanks so much for the help!!

Cheers,
 - Bob

On Jul 7, 2024, at 4:12 PM, John Fawcett via Postfix-users 
 wrote:

On 07/07/2024 18:59, Robert Fuhrer via Postfix-users wrote:

Hi,

I've got a Mac running PostFix 3.2.2, configured for local delivery 
for a single domain, call it "mydomain.net ", 
using dovecot's local delivery agent.


At the moment, there's just one relevant login user on the server, 
for which I've got PostFix delivering emails addressed to 
"myu...@mydomain.net" to that user's Maildir store. This has worked 
fine, for years.


As such, here are the relevant bits of config:

 # main.cf
 myhostname = mail.mydomain.net 
 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
 local_recipient_maps = proxy:unix:passwd.byname $alias_maps
 alias_database = hash:/etc/aliases

 # access
myu...@mydomain.net  OK

 # virtual
myu...@mydomain.net myuser@localhost

(I'm actually not sure the virtual user entry is actually necessary. 
I suspect not. Is it?)


I'd like to augment this PostFix setup to accept local delivery for 
a very limited number (say, 3-5) of specific NON-login users in the 
same domain, e.g. "otheru...@mydomain.net", also via Maildir. (I 
already have those users' mailboxes set up in Dovecot, so I can see 
their mailboxes and emails via the Dovecot IMAP service in my mail 
client.)


I understand that one shouldn't also list "@mydomain.net" as a 
virtual_mailbox_domain (since it's already $mydestination), so what 
should I do?


I'm tempted to try this:
1) Set up a fake virtual domain, say, "mydomain.virtual", just to 
map those non-login users' addresses from the external addresses 
(@mydomain.net).

2) Add a virtual mailbox domain for that domain.
3) Set up local delivery for the users in that domain (by mapping 
them to otheruser@localhost?).


or something like that.

Any advice on how to set this up properly?

Thanks in advance,
- Bob Fuhrer


Hi Bob

if email is being delivered to dovecot for the current single user 
and the same should be done for the other users, I would just list 
them as local recipients. You could just add an additional map file 
to local_recipient_maps listing these users. You could even drop the 
unix:passwd.byname lookup if you also list your existing user in that 
map. What type of user database you are using in Dovecot?


John

___

[pfx] Re: Local delivery for both login and virtual users in a single domain?

[Viktor Dukhovni via Postfix-users]

On Sun, Jul 07, 2024 at 06:02:00PM -0400, Robert Fuhrer via Postfix-users wrote:

> Oh, thanks; I should’ve realized I could just add another map to 
> local_recipient_maps. D’oh!

You're conflating many rather distinct aspects of the delivery stack.

> My Dovecot setup uses MySQL to identify users+passwords.

These is not relevant to Postfix, they facilitate the performance of:

- The dovecot LDA, when delivering mail to a givan address (user
  mailbox)

- The dovecot IMAP server, when authenticating users and serving
  the content of their mailbox.

These happen behind the scenes and are of little relevance to Postfix.

> I assume you’re asking that because (as I just discovered) PostFix
> nominally supports MySQL, but OTOH “postconf -m” doesn’t list the
> “mysql” lookup table type, so it’s not supported on the distribution
> that comes with MacOS.

No, Postfix uses system libraries to find local user accounts, and
it does not matter whether they are listed in "/etc/passwd" as a file,
or hanled by some user directory service.  If MacOS knows about the
user, Postfix will also.  On my MacOS laptop:

$ grep viktor /etc/passwd
$ postmap -q viktor unix:passwd.byname
viktor::502:20:Viktor Dukhovni:/Users/viktor:/bin/bash

Just like magic. :-)

>   # main.cf
>   home_mailbox = Maildir/

This is used by the Postfix local(8) delivery agent, but not the dovecot
LDA, if that's what you're using.  Post the output of "postconf -nf"
and "postconf -Mf" per the instructions in:

https://www.postfix.org/DEBUG_README.html#mail

making sure to preserve verbatim whitespace and linebreaks.

> but my Dovecot setup stores the base directory path in the MySQL DB.
> For non-login users, that base directory is of course not relative to
> the user's “home directory”, since non-login users have no “home
> directory”. (For login users, the base directory just happens to point
> to their home directory.)

If the "non-login" users aren't listed in "unix:passwd.byname", you can
use "fallback_transport" to hand off delivery to the dovecot LDA.  And
then sure, you need to list them in some table that makes Postfix
recognise their email addresses as valid local recipients.

main.cf:
indexed = ${default_database_type}:${config_directory}/
local_recipient_maps =
unix:passwd.byname,
$alias_maps,
${indexed}non-login

non-login:
larry   non-login user
curly   non-login user
moe non-login user
...

You can alternatively use virtual_alias_maps to rewrite them into a
"synthetic" virtual alias domain, handled by the dovecot LDA as the
virtual_transport.  I use "virtual.invalid" for that.

> I guess Dovecot’s LDA would consult the MySQL DB to find the user's
> Maildir, but perhaps PostFix’s invocation of the Dovecot LDA overrides
> the path using the “home_mailbox”. (?)

No, Postfix knows nothing about the internal workings of Dovecot, as
expected.

-- 
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Documentation Prefix

[Ralph Seichter via Postfix-users]

* Allen Coates via Postfix-users:

> I am blocking 2001:db8::/32 (of course); it's the Teredo prefix
> which I am allowing.

I misunderstood the word "these" in your OP, and the subject line only
referenced the documentation prefix, but no harm done. I don't have any
numbers for connections from Teredo addresses at hand either, but the
services I am hosting are not aimed at specific client platforms anyway.

Similar to you I am mildly curious if Teredo has any relevance beyond
Xbox and a smattering of remaining Windows 10 installations these days.

-Ralph
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] SASL authentication - first try local and then AD in postfix

[hkhk_exact10 via Postfix-users]

Hi All,

I want to setup SMTP authentication in such a way that the user should
first be looked locally (/etc/passwd) and then in AD. Is it possible to do
so? I was able to configure AD auth via sasl (cyrus), but couldn't do both.


Regards,
Sandeep
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SASL authentication - first try local and then AD in postfix

[Patrick Ben Koetter via Postfix-users]

Sandeep,

> Am 08.07.2024 um 07:37 schrieb hkhk_exact10 via Postfix-users 
> :
> 
> Hi All,
> 
> I want to setup SMTP authentication in such a way that the user should first 
> be looked locally (/etc/passwd) and then in AD. Is it possible to do so? I 
> was able to configure AD auth via sasl (cyrus), but couldn't do both. 

Cyrus SASL is able to use saslauthd in order to authenticate users in 
/etc/passwd. I don’t know what you did with Cyrus SASL to configure AD 
authentication, but assuming it would be a method called foobar you would 
configure Cyrus SASL to use the following list of password verification methods:

smtpd.conf:
pwcheck_method: saslauthd foobar
mech_list: PLAIN LOGIN

In my example Cyrus SASL would first try to authenticate an identity using 
saslauthd (/etc/passwd) and then foobar (AD). The mech_list must be limited to 
PLAIN and LOGIN, since these are the only mechanisms saslauthd supports.

HTH

Patrick



[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein



smime.p7s
Description: S/MIME cryptographic signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org