[pfx] spf

[natan via Postfix-users]

Hi
What value do you use in postfix-policyd-spf in PermError_reject ?

HELO_reject = Fail
Mail_From_reject = Fail

#update 20240706
#PermError_reject = False
PermError_reject = True
TempError_Defer = False

I don't know if that's maybe too restrictive PermError_reject
But on the other hand, the sender should have correctly configured SPF 
for his domain

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

[pfx] Re: Documentation Prefix

[Alexander Leidinger via Postfix-users]

Am 2024-07-08 06:52, schrieb 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.


Windows 10 version 1803 and later disable Teredo by default.

https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features
 -> IPv4/6 Transition Technologies

As Teredo is a MS thing (invented and propagated by them), I would call 
it dead.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


signature.asc
Description: OpenPGP digital signature
___
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

[Viktor Dukhovni via Postfix-users]

On Mon, Jul 08, 2024 at 08:39:54AM +0200, Patrick Ben Koetter via Postfix-users 
wrote:

> > 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.

If saslauthd is configured to use "pam" authentication ("saslauthd -a pam"),
then it should be possible to create a PAM config that uses either
"pam_unix" or "pam_ldap" in that order.  Something like:

/etc/pam.d/smtp
auth sufficient pam_unix.so
auth requisite  pam_ldap.so use_first_pass
...

with much additional configuration needed for pam_ldap.

-- 
Viktor.
___
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

[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: 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] 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: 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?

[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: 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?

[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: 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] 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] 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] 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] 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: 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

[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

[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

[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 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

[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] 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

[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] dnsbl submissions

[Nick Edwards via Postfix-users]

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
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Cyrus SASL summary

[Scott Kitterman via Postfix-users]

On July 5, 2024 3:03:58 PM UTC, Viktor Dukhovni via Postfix-users 
 wrote:
>On Fri, Jul 05, 2024 at 08:45:49AM -0400, Scott Kitterman via Postfix-users 
>wrote:
>
>> > Note, "undo" isn't quite what I'm suggesting, rather I hope Debian will
>> > replace the hardcoded preëmpt of the Cyrus SASL configuration directory,
>> > by a default value of $cyrus_sasl_config_path, that matches their
>> > preferred path.  This will then be subject to main.cf overrides as
>> > expected.  Presently, Debian breaks reasonable Postfix user expectations
>> > by preventing that parameter from having its documented effect.
>> 
>> I think that's doable.  There are Debian policy limitations (for good reason 
>> in my view) on what one package (Postfix in this case) can do to another 
>> (Cyrus 
>> SASL).  I need to look at the user situation a bit more closely.  There's 
>> about a quarter century of inertia behind the current situation (hard to 
>> believe Postfix has been around that long) and I don't want to accidentally 
>> break something.
>
>Nothing needs to be "done" to Cyrus of course, all I'm suggesting is
>arranging for the Postfix compiled-in default of "cyrus_sasl_config_path"
>to be the preferred Debian "/etc/postfix/sasl:/usr/lib/sasl" (IIRC),
>which then takes effect if the user did not specify an alternative
>location.
>
>This could affect some Debian users who unwittingly have some random
>explicit setting of "cyrus_sasl_config_path" in main.cf, that presently
>has no effect, so they should be duly warned as part of any upgrade.
>

Yes, that's clear enough.  It's the messing about with users that I need to 
think through before addressing (John's point, not yours).

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

[pfx] Re: Cyrus SASL summary

[Viktor Dukhovni via Postfix-users]

On Fri, Jul 05, 2024 at 08:45:49AM -0400, Scott Kitterman via Postfix-users 
wrote:

> > Note, "undo" isn't quite what I'm suggesting, rather I hope Debian will
> > replace the hardcoded preëmpt of the Cyrus SASL configuration directory,
> > by a default value of $cyrus_sasl_config_path, that matches their
> > preferred path.  This will then be subject to main.cf overrides as
> > expected.  Presently, Debian breaks reasonable Postfix user expectations
> > by preventing that parameter from having its documented effect.
> 
> I think that's doable.  There are Debian policy limitations (for good reason 
> in my view) on what one package (Postfix in this case) can do to another 
> (Cyrus 
> SASL).  I need to look at the user situation a bit more closely.  There's 
> about a quarter century of inertia behind the current situation (hard to 
> believe Postfix has been around that long) and I don't want to accidentally 
> break something.

Nothing needs to be "done" to Cyrus of course, all I'm suggesting is
arranging for the Postfix compiled-in default of "cyrus_sasl_config_path"
to be the preferred Debian "/etc/postfix/sasl:/usr/lib/sasl" (IIRC),
which then takes effect if the user did not specify an alternative
location.

This could affect some Debian users who unwittingly have some random
explicit setting of "cyrus_sasl_config_path" in main.cf, that presently
has no effect, so they should be duly warned as part of any upgrade.

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

[pfx] Re: Cyrus SASL summary

[Scott Kitterman via Postfix-users]

On Friday, July 5, 2024 4:00:59 AM EDT Viktor Dukhovni via Postfix-users wrote:
> On Thu, Jul 04, 2024 at 05:01:41PM -, John Levine via Postfix-users
> wrote:
> 
> > OK, I'll invent a user.  Perhaps if we can get Scott to undo the control
> > file  move he can add a sasl user at the same time.
> 
> 
> Note, "undo" isn't quite what I'm suggesting, rather I hope Debian will
> replace the hardcoded preëmpt of the Cyrus SASL configuration directory,
> by a default value of $cyrus_sasl_config_path, that matches their
> preferred path.  This will then be subject to main.cf overrides as
> expected.  Presently, Debian breaks reasonable Postfix user expectations
> by preventing that parameter from having its documented effect.

I think that's doable.  There are Debian policy limitations (for good reason 
in my view) on what one package (Postfix in this case) can do to another (Cyrus 
SASL).  I need to look at the user situation a bit more closely.  There's 
about a quarter century of inertia behind the current situation (hard to 
believe Postfix has been around that long) and I don't want to accidentally 
break something.

Scott K


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

[pfx] Re: Question on DKIM process ordering

[Gilgongo via Postfix-users]

On Fri, 5 Jul 2024 at 09:10, Matus UHLAR - fantomas via Postfix-users <
postfix-users@postfix.org> wrote:

> I think in case of amavis it's just the order of logs being written.
> IIUC amavis does not confirm receiving message from postfix until after
> it's
> scanned and passed further, which is why new scanned message is logger
> before


OK that's what I was hoping.


>
> BTW, amavis can DKIM-sign the message itself.
>

Yes, it's just that we already have OpenDKIM signing for 200+ domains so I
thought I'd leave that alone.


> >Unfortunately, I can't tell whether the DKIM sig is OK or not in my test
> >setup, but I'd like to ensure it's the last thing to happen before
> sending.
> >How can I do that?
>
> deliver it to mailbox locally and run spamassassin scan, it should tell
> you
> whether the signature is correct.
>
>
Ah yes, thanks! :-)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Blocking by IP using check_helo_access

[Linkcheck via Postfix-users]

Thank you for your reply, Viktor.

So I've been wrong for the past few years in thinking it was working. 
Surprising (to me!) but yet another warning to not pick up "working 
configurations" from web sites (and possibly mis-read them). :(


I understand what you're saying. I may have mistaken check_helo_a_access 
 as a mis-print for check_helo_access. I'll look more carefully at the 
options.


Again, thank you for your response. :)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question on DKIM process ordering

[Matus UHLAR - fantomas via Postfix-users]

On 05.07.24 08:42, Gilgongo via Postfix-users wrote:

I'm setting up a server to handle outbound mail for sasl auth accounts and
would like to scan that mail for spam and malware before DKIM signing
because I assume scanning might potentially add headers that could break
the sig.

Right now I have the following (extract) in my Amavis conf:

$interface_policy{'10026'} = 'ORIGINATING';
$policy_bank{'ORIGINATING'}
 # forward to a smtpd service providing DKIM signing service
 forward_method => 'smtp:[127.0.0.1]:10027',
 notify_method => 'smtp:[127.0.0.1]:10025',

With master.cf as:

submission  inet  n   -   n-  -   smtpd
... configs...
 -o content_filter=smtp-amavis:[127.0.0.1]:10026

smtp-amavisunix--n-2smtp
 -o smtp_data_done_timeout=1200
 -o smtp_send_xforward_command=yes
 -o disable_dns_lookups=yes
 -o max_use=20

# For sending notifications about actions
127.0.0.1:10025inetn-n--smtpd
 -o syslog_name=notify
 configs...

# For OpenDKIM signing
127.0.0.1:10027inetn-n--smtpd
 ... configs...
 -o smtpd_milters=inet:127.0.0.1:8891

So I assume DKIM should come last. But the logs imply the spam/virus check
is done after?


I think in case of amavis it's just the order of logs being written.
IIUC amavis does not confirm receiving message from postfix until after it's 
scanned and passed further, which is why new scanned message is logger 
before 


postfix/cleanup[1685]: BB20880330:
message-id=<20240705073351.001500@fre.localdomain>
opendkim[700]: BB20880330: DKIM-Signature field added (s=dkim20200516, d=
bakerbates.com)
postfix/qmgr[1558]: BB20880330: from=, size=945, nrcpt=1
(queue active)
amavis[1563]: (01563-01) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL
[192.168.0.241]:51084 [etc.]
postfix/smtp[1686]: 76C0C80266: to=,
relay=127.0.0.1[127.0.0.1]:10026, [etc.]
postfix/qmgr[1558]: 76C0C80266: removed


If you checked all logs of messages BB20880330 and 76C0C80266 and didn't 
remove important parts, it should be visible that the order is:


- postfix handles incoming message 76C0C80266 from client to amavis at 
  [127.0.0.1]:10026

- amavis scans message and passes it to postfix at 127.0.0.1:10027
- postfix at 127.0.0.1:10027 receives message BB20880330 and passes it to 
  opendkim and other milters
- amavis logs status of message, including message ID sent by postfix, in 
  this case BB20880330

- postfix logs removing of message 76C0C80266
- ...

BTW, amavis can DKIM-sign the message itself.


Unfortunately, I can't tell whether the DKIM sig is OK or not in my test
setup, but I'd like to ensure it's the last thing to happen before sending.
How can I do that?


deliver it to mailbox locally and run spamassassin scan, it should tell you 
whether the signature is correct.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question on DKIM process ordering

[Viktor Dukhovni via Postfix-users]

On Fri, Jul 05, 2024 at 08:42:31AM +0100, Gilgongo via Postfix-users wrote:

> # For OpenDKIM signing
> 127.0.0.1:10027inetn-n--smtpd
>   ... configs...
>   -o smtpd_milters=inet:127.0.0.1:8891
> 
> So I assume DKIM should come last. But the logs imply the spam/virus check
> is done after?

It does.

> postfix/cleanup[1685]: BB20880330:
> message-id=<20240705073351.001500@fre.localdomain>
> opendkim[700]: BB20880330: DKIM-Signature field added (s=dkim20200516, d=
> bakerbates.com)
> postfix/qmgr[1558]: BB20880330: from=, size=945, nrcpt=1
> (queue active)
> amavis[1563]: (01563-01) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL
> [192.168.0.241]:51084 [etc.]

The DKIM signature is added by the milter *before* the "." response is
sent to the client (amavis), which means amavis will log delivery after
the milter does its job, but amavis did process the message content
first.

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

[pfx] Re: Cyrus SASL summary

[Viktor Dukhovni via Postfix-users]

On Thu, Jul 04, 2024 at 05:01:41PM -, John Levine via Postfix-users wrote:

> OK, I'll invent a user.  Perhaps if we can get Scott to undo the control file
> move he can add a sasl user at the same time.

Note, "undo" isn't quite what I'm suggesting, rather I hope Debian will
replace the hardcoded preëmpt of the Cyrus SASL configuration directory,
by a default value of $cyrus_sasl_config_path, that matches their
preferred path.  This will then be subject to main.cf overrides as
expected.  Presently, Debian breaks reasonable Postfix user expectations
by preventing that parameter from having its documented effect.

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

[pfx] Question on DKIM process ordering

[Gilgongo via Postfix-users]

I'm setting up a server to handle outbound mail for sasl auth accounts and
would like to scan that mail for spam and malware before DKIM signing
because I assume scanning might potentially add headers that could break
the sig.

Right now I have the following (extract) in my Amavis conf:

$interface_policy{'10026'} = 'ORIGINATING';
$policy_bank{'ORIGINATING'}
  # forward to a smtpd service providing DKIM signing service
  forward_method => 'smtp:[127.0.0.1]:10027',
  notify_method => 'smtp:[127.0.0.1]:10025',

With master.cf as:

submission  inet  n   -   n-  -   smtpd
... configs...
  -o content_filter=smtp-amavis:[127.0.0.1]:10026

smtp-amavisunix--n-2smtp
  -o smtp_data_done_timeout=1200
  -o smtp_send_xforward_command=yes
  -o disable_dns_lookups=yes
  -o max_use=20

# For sending notifications about actions
127.0.0.1:10025inetn-n--smtpd
  -o syslog_name=notify
  configs...

# For OpenDKIM signing
127.0.0.1:10027inetn-n--smtpd
  ... configs...
  -o smtpd_milters=inet:127.0.0.1:8891

So I assume DKIM should come last. But the logs imply the spam/virus check
is done after?

postfix/cleanup[1685]: BB20880330:
message-id=<20240705073351.001500@fre.localdomain>
opendkim[700]: BB20880330: DKIM-Signature field added (s=dkim20200516, d=
bakerbates.com)
postfix/qmgr[1558]: BB20880330: from=, size=945, nrcpt=1
(queue active)
amavis[1563]: (01563-01) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL
[192.168.0.241]:51084 [etc.]
postfix/smtp[1686]: 76C0C80266: to=,
relay=127.0.0.1[127.0.0.1]:10026, [etc.]
postfix/qmgr[1558]: 76C0C80266: removed

Unfortunately, I can't tell whether the DKIM sig is OK or not in my test
setup, but I'd like to ensure it's the last thing to happen before sending.
How can I do that?

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

[pfx] Re: Cyrus SASL summary

[John Levine via Postfix-users]

According to Viktor Dukhovni via Postfix-users :
>I don't recommend running "saslauthd" as the "postfix" user, better to
>create a suitable dedicated user instead.

OK, I'll invent a user.  Perhaps if we can get Scott to undo the control file
move he can add a sasl user at the same time.

>> Other than that I'm using the default configs in the documentation and
>> it seems to work. I've been able to connect to port 465, auth, and
>> send myself test messages.
>
>Presumably, now with the "aaa" user no longer in your "sasldb".

This is a test setup in a virtual machine on my laptop.  The names of the
users don't really matter.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

[pfx] Re: Cyrus SASL summary

[Wietse Venema via Postfix-users]

Viktor Dukhovni via Postfix-users:
> > * Both postfix and the daemon need to be able to open and read and
> > write the socket. The sasl package adds a sasl group but not a sasl
> > user, so I added postfix to the users for the sasl group, and run the
> > daemon as postfix:sasl. The user/group for the daemon is set in
> > /etc/systemd/system/saslauthd.service.d/user.conf
> 
> I don't recommend running "saslauthd" as the "postfix" user, better to
> create a suitable dedicated user instead.

+1. Please don't run other programs with the 'postfix' uid or
'postdrop' gid. These are part of a multi-layer defense.

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

[pfx] Re: Cyrus SASL summary

[Matus UHLAR - fantomas via Postfix-users]

On Wed, Jul 03, 2024 at 09:48:06PM -0400, John Levine via Postfix-users wrote:

* Both postfix and the daemon need to be able to open and read and
write the socket. The sasl package adds a sasl group but not a sasl
user, so I added postfix to the users for the sasl group, and run the
daemon as postfix:sasl. The user/group for the daemon is set in
/etc/systemd/system/saslauthd.service.d/user.conf


bundled documentation  /usr/share/doc/sasl2-bin/README.Debian.gz contains 
all required information to make that working.
I have posted that info here in the past - I have extracted it from that 
file.



On 04.07.24 16:37, Viktor Dukhovni via Postfix-users wrote:

I don't recommend running "saslauthd" as the "postfix" user, better to
create a suitable dedicated user instead.


saslauthd runs as root user by default, the access for both daemons is 
assured by adding postfix to the sasl group and allowing group access for 
sasl group to the proper directory.


The file I mentioned above contains information on running saslauthd as 
saslaush user/group under systemd, haven't tried that.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: DANE and STS

[Viktor Dukhovni via Postfix-users]

On Thu, Jun 27, 2024 at 08:32:08PM +0200, Gerd Hoerst via Postfix-users wrote:

> I had the setup with R3 running for years w/o problems  but now i have also
> R11/12/13/14 as backup entries

I hope that also includes R10.  It is simplest/best to force an
expedited renewal, then you'll get one of the "R1x" CAs as your
issuer, and will no longer need the TLSA record matching R3.

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

[pfx] Re: Cyrus SASL summary

[Viktor Dukhovni via Postfix-users]

On Wed, Jul 03, 2024 at 09:48:06PM -0400, John Levine via Postfix-users wrote:

> * Debian moved the sasl configuration file to a nonstandard place
> /etc/postfix/sasl/smtpd.conf
> Dunno how I would have figured that out if someone here hadn't told me.

This is unfortunate, and I rather hope that Scott Kitterman is still
reading this thread, the Debian patch needs to be reworked, as suggested
in my previous post.

> * Both postfix and the daemon need to be able to open and read and
> write the socket. The sasl package adds a sasl group but not a sasl
> user, so I added postfix to the users for the sasl group, and run the
> daemon as postfix:sasl. The user/group for the daemon is set in
> /etc/systemd/system/saslauthd.service.d/user.conf

I don't recommend running "saslauthd" as the "postfix" user, better to
create a suitable dedicated user instead.

> Other than that I'm using the default configs in the documentation and
> it seems to work. I've been able to connect to port 465, auth, and
> send myself test messages.

Presumably, now with the "aaa" user no longer in your "sasldb".

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

[pfx] Cyrus SASL summary

[John Levine via Postfix-users]

I think these are the main things I learned:

* Debian moved the sasl configuration file to a nonstandard place
/etc/postfix/sasl/smtpd.conf
Dunno how I would have figured that out if someone here hadn't told me.

* The socket that the sasl daemon uses has to be inside the postfix
chroot, by default /var/spool/postfix/var/run/saslauthd. This has to
be patched into the startup script at /etc/default/saslauthd

* Both postfix and the daemon need to be able to open and read and
write the socket. The sasl package adds a sasl group but not a sasl
user, so I added postfix to the users for the sasl group, and run the
daemon as postfix:sasl. The user/group for the daemon is set in
/etc/systemd/system/saslauthd.service.d/user.conf

* The directories in the path to the socket also have to be readable
by postfix and the daemon. I don't see any way to do that than manual
chown and chmod.

Other than that I'm using the default configs in the documentation and
it seems to work. I've been able to connect to port 465, auth, and
send myself test messages.

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

[pfx] Re: DANE and STS

[Jeff Pang via Postfix-users]

Does LE company have commercial revenue? I thought it was a non-profit 
organization.




generate yourself and don't have to deal with LE's high turnover
intermediaries nonsense.


--
Jeff Pang
j...@simplemail.co.in
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: DANE and STS

[Matt Kinni via Postfix-users]

On 2024-07-03 17:25, raf via Postfix-users wrote:
> So it's not really easier to just used self-signed
> certificates since you'll want a CA-signed certificate
> for submission anyway, and you can have the same key
> for both.

Well I control what devices use the submission port, so I can also just
install my self-signed CA there (eg. on my iphone) so this isn't a
problem.  But I see your point.

-- 
Matt

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

[pfx] Re: DANE and STS

[raf via Postfix-users]

On Wed, Jul 03, 2024 at 05:12:35PM -0700, Matt Kinni via Postfix-users 
 wrote:

> On 2024-06-27 05:24, Viktor Dukhovni via Postfix-users wrote:
> 
> > Publishing just "R10" will soon fail, when you get a cert from "R11" or
> > one of the backup issuers R12, R13 or R14.  You MUST publish them all to
> > avoid sudden breakage surprises.
> 
> Isn't it easier to just used self-signed certificates in this case?  I
> really don't understand the benefits of letsencrypt in the mail server
> use case, when DANE works just fine with certificates that you can
> generate yourself and don't have to deal with LE's high turnover
> intermediaries nonsense.
> 
> -- 
> Matt

Letsencrypt is fine if you prevent the key itself
changing all the time, and if you use 3 1 1 TLSA
records. Having the key signed by them means that you
can use the same key for ports 465 and 587 as you do
for port 25 (and for any web server on the same host).

There are email clients that don't like self-signed
certificates for submission. And 3 1 1 means that the
intermediaries are irrelevant for the purposes of DANE
verification on port 25. They are only relevant for CA
verification on other ports.

So it's not really easier to just used self-signed
certificates since you'll want a CA-signed certificate
for submission anyway, and you can have the same key
for both.

cheers,
raf

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

[pfx] Re: DANE and STS

[Matt Kinni via Postfix-users]

On 2024-06-27 05:24, Viktor Dukhovni via Postfix-users wrote:

> Publishing just "R10" will soon fail, when you get a cert from "R11" or
> one of the backup issuers R12, R13 or R14.  You MUST publish them all to
> avoid sudden breakage surprises.

Isn't it easier to just used self-signed certificates in this case?  I
really don't understand the benefits of letsencrypt in the mail server
use case, when DANE works just fine with certificates that you can
generate yourself and don't have to deal with LE's high turnover
intermediaries nonsense.

-- 
Matt

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

[pfx] Re: Still no luck with Cyrus SASL

[John Levine via Postfix-users]

It appears that Patrick Ben Koetter via Postfix-users  said:
>IIRC Debian patches Postfix and expects smtpd.conf to be located in
>/etc/postfix/sasl/smtpd.conf. Have you tried this?

I just did and it worked.

Thanks, everyone.  Now I have to back out my hacks one by one and make sure
I understand which ones matter.

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

[pfx] Re: Still no luck with Cyrus SASL

[Matus UHLAR - fantomas via Postfix-users]

On 02.07.24 17:15, John R. Levine via Postfix-users wrote:
[...]

In main.cf it has the debian default config, and I added this:

smtp_sasl_type = cyrus
smtpd_sasl_path = smtpd
cyrus_sasl_config_path = /usr/lib/sasl2


Try commenting this out.


Per the instructions in the postfix SASL page and the Cyrus SASL doc
page I put this both in /etc/sasl2/smtpd.conf and in
/usr/lib/sasl2/smtpd.conf since it's not clear which postfix prefers:


Have you tried /etc/postfix/sasl/smtpd.conf
as I wrote in my last e-mail?

https://marc.info/?l=postfix-users=171947907929528=2

This also contains oter instructions I have repeatedly followed to make 
authentication on debian working with cyrus-sasl.


Just note that I used system-wide accounts, not sasldb2/saslpasswd2.


   pwcheck_method: saslauthd
   mech_list: PLAIN LOGIN

The default location for the saslauthd socket is /var/run/saslauthd
but postfix is chrooted so I've tried having the daemon listen there
or at /var/spool/postfix/var/run/saslauthd.  The daemon works fine
either way, per the test above, but postfix doesn't talk to it.

What am I missing?


try:

# ls -ld /var/spool/postfix/var/run/saslauthd
drwxr-x--- 2 root sasl 4096 Apr 25 17:29 /var/spool/postfix/var/run/saslauthd


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Still no luck with Cyrus SASL

[Wietse Venema via Postfix-users]

Use strace to find out what pathname Postfix (through libsasl) is
trying to connect to.

1 - Connect to Postfix with gnutls-cli or "openssl s_client".

2 - Run "strace -p pid-of-smtpd -o output-file".

3 - Send EHLO, AUTH, QUIT.

4 - Look in the trace created in [2] and populated in [3].

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

[pfx] Re: Still no luck with Cyrus SASL

[Viktor Dukhovni via Postfix-users]

On Wed, Jul 03, 2024 at 01:43:23PM +0200, Patrick Ben Koetter via Postfix-users 
wrote:

> > If not, or, in any case, you might specify
> > 
> > saslauthd_path: /var/run/saslauthd/mux
> > 
> > in the "smtpd.conf" file, once it is in the correct (for Debian)
> > directory.  Note that this setting does include the "/mux" suffix.
> 
> IIRC Debian patches Postfix and expects smtpd.conf to be located in
> /etc/postfix/sasl/smtpd.conf. Have you tried this?

See:


https://salsa.debian.org/postfix-team/postfix-dev/-/blob/debian/master/debian/patches/07_sasl_config.diff?ref_type=heads#L73-79

path = concatenate(var_config_dir, "/", "sasl:/usr/lib/sasl", (char *) 0);

In other words, Debian updates Postfix to search for the configuration in 

- ${config_directory}/sasl  (typically /etc/postfix/sasl)
- /usr/lib/sasl

regardless of the main.cf setting of cyrus_sasl_config_path.  Debian
really should stop doing that, and instead set a backwards-compatible
Debian-specific *default* for the config path, and let any main.cf
overrides take effect.

[ Scott Kitterman, any chance??? ]

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

[pfx] Re: Still no luck with Cyrus SASL

[Patrick Ben Koetter via Postfix-users]

John,

* Viktor Dukhovni via Postfix-users :
> On Tue, Jul 02, 2024 at 11:24:53PM -0400, John Levine via Postfix-users wrote:
> 
> > >Have you posted "postconf -nf" and "postconf -Mf" output (with as-is
> > >whitespace, including line-breaks)?
> > 
> > I will, see below.
> 
> Thanks, generally best to do that early when delving into configuration
> conundrums.
> 
> > >What's the evidence that "saslauthd" is not used?
> > 
> > I have saslauthd in debug mode so it reports when anything talks to
> > it. As I said, the sasl test client works fine and it reports that, so
> > I know that works.
> 
> That is, saslauthd(8) is listening on the socket you specified in your
> testsaslauthd(8) command-line:
> 
> $ testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux ...
> 
> which you correctly specify inside the Postfix chroot jail, but, is
> "/var/run/saslauthd" the actual directory compiled into the Debian SASL
> library?  If not, or, in any case, you might specify
> 
> saslauthd_path: /var/run/saslauthd/mux
> 
> in the "smtpd.conf" file, once it is in the correct (for Debian)
> directory.  Note that this setting does include the "/mux" suffix.

IIRC Debian patches Postfix and expects smtpd.conf to be located in
/etc/postfix/sasl/smtpd.conf. Have you tried this?

p@rick


-- 
[*] sys4 AG

https://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, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

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

[pfx] Re: Still no luck with Cyrus SASL

[Viktor Dukhovni via Postfix-users]

On Tue, Jul 02, 2024 at 11:24:53PM -0400, John Levine via Postfix-users wrote:

> >Have you posted "postconf -nf" and "postconf -Mf" output (with as-is
> >whitespace, including line-breaks)?
> 
> I will, see below.

Thanks, generally best to do that early when delving into configuration
conundrums.

> >What's the evidence that "saslauthd" is not used?
> 
> I have saslauthd in debug mode so it reports when anything talks to
> it. As I said, the sasl test client works fine and it reports that, so
> I know that works.

That is, saslauthd(8) is listening on the socket you specified in your
testsaslauthd(8) command-line:

$ testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux ...

which you correctly specify inside the Postfix chroot jail, but, is
"/var/run/saslauthd" the actual directory compiled into the Debian SASL
library?  If not, or, in any case, you might specify

saslauthd_path: /var/run/saslauthd/mux

in the "smtpd.conf" file, once it is in the correct (for Debian)
directory.  Note that this setting does include the "/mux" suffix.

> >> 535 5.7.8 Error: authentication failed: authentication failure
> >
> >I gather you generated the "auth plain ..." yourself. ...
> 
> If I could get it to talk to saslauthd at all then we might worry
> about the details of what it's passing to it. Per a previous message
> I'll try the socket locations he suggests.

Did you get a chance to check the ancestor directories and socket
ownership and permissions?

> smtp_sasl_type = cyrus

I don't see a corresponding setting of "smtpd_sasl_type".

> smtpd_sasl_auth_enable = yes

I would set this to "no".

> smtpd_sasl_mechanism_filter = login, plain
> smtpd_sasl_path = smtpd
> smtpd_tls_auth_only = yes

This looks fine.

> submissions inet n   -   y   -   -   smtpd
> -o syslog_name=postfix/submissions
> -o smtpd_tls_wrappermode=yes
> -o smtpd_sasl_auth_enable=yes
> -o smtpd_reject_unlisted_recipient=no
> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Indeed chrooted.

In summary:

- main.cf: smtpd_sasl_type = cyrus
- Ensure correct (for Debian) location of smtpd.conf
- smtpd.conf: saslauthd_path: /var/run/saslauthd/mux
- Check directory and socket permissions, the postfix
  user or its *primary* group should be able to open
  the socket for read/write.

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

[pfx] Re: Still no luck with Cyrus SASL

[John Levine via Postfix-users]

It appears that Viktor Dukhovni via Postfix-users  
said:
>Have you posted "postconf -nf" and "postconf -Mf" output (with as-is
>whitespace, including line-breaks)?

I will, see below.

>> But when I try to get postfix to authenticate, I cannot get it even to talk 
>> to
>> the daemon.
>
>What's the evidence that "saslauthd" is not used?

I have saslauthd in debug mode so it reports when anything talks to
it. As I said, the sasl test client works fine and it reports that, so
I know that works.

>> 535 5.7.8 Error: authentication failed: authentication failure
>
>I gather you generated the "auth plain ..." yourself. ...

If I could get it to talk to saslauthd at all then we might worry
about the details of what it's passing to it. Per a previous message
I'll try the socket locations he suggests.

# postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 3.6
cyrus_sasl_config_path = /usr/lib/sasl2
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 0
mydestination = test.qy, $myhostname, debian12.qy, localhost.qy, localhost
myhostname = debian12.qy
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_sasl_type = cyrus
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_mechanism_filter = login, plain
smtpd_sasl_path = smtpd
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level = may

# postconf -Mf
smtp   inet  n   -   y   -   -   smtpd
submission inet  n   -   y   -   -   smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
submissions inet n   -   y   -   -   smtpd
-o syslog_name=postfix/submissions
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
pickup unix  n   -   y   60  1   pickup
cleanupunix  n   -   y   -   0   cleanup
qmgr   unix  n   -   n   300 1   qmgr
tlsmgr unix  -   -   y   1000?   1   tlsmgr
rewriteunix  -   -   y   -   -   trivial-rewrite
bounce unix  -   -   y   -   0   bounce
defer  unix  -   -   y   -   0   bounce
trace  unix  -   -   y   -   0   bounce
verify unix  -   -   y   -   1   verify
flush  unix  n   -   y   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   y   -   -   smtp
relay  unix  -   -   y   -   -   smtp
-o syslog_name=postfix/$service_name
showq  unix  n   -   y   -   -   showq
error  unix  -   -   y   -   -   error
retry  unix  -   -   y   -   -   error
discardunix  -   -   y   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   y   -   -   lmtp
anvil  unix  -   -   y   -   1   anvil
scache unix  -   -   y   -   1   scache
postlogunix-dgram n  -   n   -   1   postlogd
maildrop   unix  -   n   n   -   -   pipe flags=DRXhu
user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp   unix  -   n   n   -   -   pipe flags=Fqhu
user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix  -   n   n   -   -   pipe flags=F user=ftn
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp  unix  -   n   n   -   -   pipe flags=Fq.
user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n   n   -   2   pipe flags=R
user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
${user} ${extension}
mailmanunix  -   n   n   -   -   pipe flags=FRX
user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py 

[pfx] Re: Still no luck with Cyrus SASL

[Viktor Dukhovni via Postfix-users]

On Tue, Jul 02, 2024 at 05:15:28PM -0400, John R. Levine via Postfix-users 
wrote:

> I've put a few dummy user entries in /etc/sasldb2 and set up the saslauthd
> service, which for now I'm running in debug mode.  When I try sending a test
> query the daemon gets it and replies:

Have you posted "postconf -nf" and "postconf -Mf" output (with as-is
whitespace, including line-breaks)?

> # testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux -u aaa -r test.qy 
> -p 

The username here is "aaa", while in the (later, below) Postfix debug
logging the AUTH PLAIN data decodes to:

^@a...@test.qy^@

in which the username is "a...@test.qy".  These are not the same.

Also, (though given the above, perhaps not your problem) what are the
permissions on the socket and leading path components?  Using a shell
that supports csh-style brace expansion:

# ls -ld /var/spool/postfix{,/var{,/run,{/saslauthd{,/mux

> But when I try to get postfix to authenticate, I cannot get it even to talk to
> the daemon.

What's the evidence that "saslauthd" is not used?

> $ gnutls-cli --no-ca-verification --crlf 172.16.157.132:465
> [ cert stuff skipped ]

We should perhaps add SASL-client support to posttls-finger(1).
You should not need "gnutls-cli" to test a Postfix server.

> - Simple Client Mode:
> 
> 220 debian12.qy ESMTP Postfix (Debian/GNU)
> ehlo bob
> 250-debian12.qy
> 250-PIPELINING
> 250-SIZE 1024
> 250-VRFY
> 250-ETRN
> 250-AUTH LOGIN PLAIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250-DSN
> 250-SMTPUTF8
> 250 CHUNKING
> auth plain AGFhYUB0ZXN0LnF5AGFhYWE=
> 535 5.7.8 Error: authentication failed: authentication failure

I gather you generated the "auth plain ..." yourself.  Note the
above reported "authc" (authentication username) discrepancy,
this username comes with an "@" suffix:

^@a...@test.qy^@

> When I look at the logs, it gets the user name OK but can't authenticate
> 
> Jul 02 11:47:20 debian12 postfix/submissions/smtpd[9563]: connect from 
> unknown[172.16.157.1]
> Jul 02 11:47:32 debian12 postfix/submissions/smtpd[9563]: warning: SASL 
> authentication failure: Password verification failed
> Jul 02 11:47:32 debian12 postfix/submissions/smtpd[9563]: warning: 
> unknown[172.16.157.1]: SASL plain authentication failed: authentication 
> failure,
> sasl_username=a...@test.qy

Wrong username.

> In main.cf it has the debian default config, and I added this:
> 
> smtp_sasl_type = cyrus
> smtpd_sasl_path = smtpd
> cyrus_sasl_config_path = /usr/lib/sasl2

IIRC (unless recently fixed), Debian systems patch Postfix in a manner
tha effectively ignores cyrus_sasl_config_path, and uses some hard-coded
directory instead.

> Per the instructions in the postfix SASL page and the Cyrus SASL doc
> page I put this both in /etc/sasl2/smtpd.conf

Perhaps that's the hard-coded location I don't recall ATM.

> and in /usr/lib/sasl2/smtpd.conf since it's not clear which postfix
> prefers:
> 
> pwcheck_method: saslauthd
> mech_list: PLAIN LOGIN

Were it not for Debian's flawed patch, the directory should be as
specified in main.cf, but once Postfix is modified, the warranty is void
and you have to ask the Debian maintainers... :-)

> The default location for the saslauthd socket is /var/run/saslauthd
> but postfix is chrooted

For that, it would be helpful to have at least (whichever matches
master.cf on your system):

$ postconf -Mf submissions/inet
$ postconf -Mf smtps/inet
$ postconf -Mf 465/inet

if not the complete "postconf -Mf" output.

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

[pfx] Re: News about The new Postfix book ?

[Jeff Peng via Postfix-users]

I will order one as well.



Here's a link to the web site where you can order it:

https://www.tiltedwindmillpress.com/product/ryoms-preorder/

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

[pfx] Re: News about The new Postfix book ?

[Phil Biggs via Postfix-users]

Wednesday, July 3, 2024, 8:03:38 AM, Jean-François Bachelet via Postfix-users  
wrote:

> Hello folks ^^)

> There was a new Postfix book in the writing announced on the list, is it 
> finished and where to find/buy it ?

> Thanks by advance :)

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


It seems to be finished but not available for delivery just yet.

Here's a link to the web site where you can order it:  

https://www.tiltedwindmillpress.com/product/ryoms-preorder/


-- 
Cheers,
Phil

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

[pfx] Re: Still no luck with Cyrus SASL

[Wietse Venema via Postfix-users]

John R. Levine via Postfix-users:
> The daemon works fine either way, per the test above, but postfix
> doesn't talk to it.

I can't share first-hand experiences, but I know that is Postfix
never talks to saslauthd. Instead, libsasl does the talking.

It may be instructive to compare strace outputs for the Postfix
smtpd process with strace for the testsaslauthd command. If Postfix
is barking up the wrong tree, then strace should reveal that.

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

[pfx] Re: Still no luck with Cyrus SASL

[Jim P. via Postfix-users]

On Tue, 2024-07-02 at 17:15 -0400, John R. Levine via Postfix-users
wrote:
> In main.cf it has the debian default config, and I added this:
> 
> smtp_sasl_type = cyrus
> smtpd_sasl_path = smtpd

Those are the defaults in Debian. Do you find 'cyrus' when you run
'postconf -A'?

> cyrus_sasl_config_path = /usr/lib/sasl2

The Debian default is empty (which is what I use), but I do find files
from sasl2-bin located there.

> smtpd_sasl_auth_enable = yes
> smtpd_tls_auth_only = yes

I have both of those set to "no" on my Debian system.

> smtpd_sasl_mechanism_filter = login, plain

I use the Debian default of:
  smtpd_sasl_mechanism_filter = !external, static:rest

> Per the instructions in the postfix SASL page and the Cyrus SASL doc
> page I put this both in /etc/sasl2/smtpd.conf and in
> /usr/lib/sasl2/smtpd.conf since it's not clear which postfix prefers:
> 
>  pwcheck_method: saslauthd
>  mech_list: PLAIN LOGIN

On my Debian systems that file is located at
/etc/postfix/sasl/smtpd.conf and contains:

pwcheck_method: saslauthd
auxprop_plugin: sasldb
mech_list: digest cram-md5


> The default location for the saslauthd socket is /var/run/saslauthd
> but postfix is chrooted so I've tried having the daemon listen there
> or at /var/spool/postfix/var/run/saslauthd.  The daemon works fine
> either way, per the test above, but postfix doesn't talk to it.

Debian uses /etc/default/saslauthd for saslauthd startup options, 
Here are the options I use in that file:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="sasldb"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/spool/postfix/saslauthd"


File ownership/perms:

~$ ls -dl /var/spool/postfix/saslauthd
drwx--x--- 2 root sasl 4096 Jun 29 13:46 /var/spool/postfix/saslauthd

Postfix is a member of sasl group:

~$ grep sasl /etc/group
sasl:x:45:postfix

On Debian based systems you will need to edit
/usr/lib/postfix/configure-instance.sh
  and append 'etc/sasldb' to the list of FILES
  that postfix copies to the chroot when it starts:

~$ ls -al /var/spool/postfix/etc/sasldb2 
-rw-r--r-- 1 root root 12288 Jun 22 23:36 /var/spool/postfix/etc/sasldb2

After all that is in place, I use the following
  to add/list/delete accounts: 
saslpasswd2 -c me@desktop
saslpasswd2 -c me@oldPC
sasldblistusers2

hth,

-Jim P.

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

[pfx] News about The new Postfix book ?

[Jean-François Bachelet via Postfix-users]

Hello folks ^^)

There was a new Postfix book in the writing announced on the list, is it 
finished and where to find/buy it ?


Thanks by advance :)

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

[pfx] Still no luck with Cyrus SASL

[John R. Levine via Postfix-users]

I've been poking at this for a week with no luck at all.  I presume I am 
doing something dumb but I can't see what.


I have what I think is a bog standard debian systen running in a virtual 
machine on my laptop, with the usual postfix and sasl packages.  All of 
the mail addresses and mailboxes are in a virtual domain so I want to use 
sasldb to authenticate.


Postfix has cyrus and dovecot support, per postconf -a

I've put a few dummy user entries in /etc/sasldb2 and set up the saslauthd 
service, which for now I'm running in debug mode.  When I try sending a 
test query the daemon gets it and replies:


# testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux -u aaa -r test.qy 
-p 

saslauthd[8239] :released accept lock
saslauthd[8239] :attempting a read lock on slot: 742
saslauthd[8239] :[login=aaa] [service=imap] [realm=test.qy]: not found, update 
pending
saslauthd[8239] :attempting to release lock on slot: 742
saslauthd[8239] :attempting a write lock on slot: 742
saslauthd[8239] :lookup committed
saslauthd[8239] :attempting to release lock on slot: 742
saslauthd[8239] :auth success: [user=aaa] [service=imap] [realm=test.qy] 
[mech=sasldb]
saslauthd[8239] :response: OK
saslauthd[8239] :acquired accept lock

0: OK "Success."

But when I try to get postfix to authenticate, I cannot get it even to talk to
the daemon.  Connecting to the submission port and doing auth works fine as far
as it goes:

$ gnutls-cli --no-ca-verification --crlf 172.16.157.132:465
[ cert stuff skipped ]
- Simple Client Mode:

220 debian12.qy ESMTP Postfix (Debian/GNU)
ehlo bob
250-debian12.qy
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
auth plain AGFhYUB0ZXN0LnF5AGFhYWE=
535 5.7.8 Error: authentication failed: authentication failure
quit
221 2.0.0 Bye

When I look at the logs, it gets the user name OK but can't authenticate

Jul 02 11:47:20 debian12 postfix/submissions/smtpd[9563]: connect from 
unknown[172.16.157.1]
Jul 02 11:47:32 debian12 postfix/submissions/smtpd[9563]: warning: SASL 
authentication failure: Password verification failed
Jul 02 11:47:32 debian12 postfix/submissions/smtpd[9563]: warning: 
unknown[172.16.157.1]: SASL plain authentication failed: authentication failure,
sasl_username=a...@test.qy
Jul 02 11:47:34 debian12 postfix/submissions/smtpd[9563]: disconnect from 
unknown[172.16.157.1] ehlo=1 auth=0/1 quit=1 commands=2/3

In main.cf it has the debian default config, and I added this:

smtp_sasl_type = cyrus
smtpd_sasl_path = smtpd
cyrus_sasl_config_path = /usr/lib/sasl2
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes
smtpd_sasl_mechanism_filter = login, plain

Per the instructions in the postfix SASL page and the Cyrus SASL doc
page I put this both in /etc/sasl2/smtpd.conf and in
/usr/lib/sasl2/smtpd.conf since it's not clear which postfix prefers:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

The default location for the saslauthd socket is /var/run/saslauthd
but postfix is chrooted so I've tried having the daemon listen there
or at /var/spool/postfix/var/run/saslauthd.  The daemon works fine
either way, per the test above, but postfix doesn't talk to it.

What am I missing?

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Postfix unable to locate opendmarc.sock file

[EML via Postfix-users]

This is a reply to an old (2021/11/11) message I found on 
mail-archive.com, so it won't thread. The OP wrote:



I see this error message in my mail.log file:
Nov 11 19:37:52 mail postfix/smtpd[5942]: warning: connect to Milter
service local:opendmarc/opendmarc.sock: No such file or directory
In the main.cf file, I have this line:
smtpd_milters = 
local:opendkim/opendkim.sock,local:opendmarc/opendmarc.sock,

local:spamass/spamass.sock
There were various replies along the lines of 'this syntax is invalid'. 
However, this syntax is documented, and works on Ubuntu 22.04, at least 
(the current MILTER_README.html says "On many systems, local is a 
synonym for unix", and I've been doing this for many years).


I have one Ubuntu 22.04 system with this in main.cf:

smtpd_milters = inet:localhost:8891,local:opendmarc/opendmarc.sock

and this in opendmarc.conf:

Socket local:/var/spool/postfix/opendmarc/opendmarc.sock

This works, with mail.log reporting an opendmarc pass. Not particularly 
interesting, but a second identical system didn't work, and gave exactly 
the error message reported above. On the second system, there was an 
existing socket file in /var/run/opendmarc, and this was preventing 
opendmarc from creating the correct socket file, in 
/var/spool/postfix/opendmarc. Restarting postfix and opendmarc had no 
effect, but a reboot fixed the second system, and it now reports 
opendmarc passes.


On the second system, I also tried changing main.cf to

smtpd_milters = inet:localhost:8891,unix:/opendmarc/opendmarc.sock

and this also works. MILTER_README.html states that "an absolute 
pathname is interpreted relative to the Postfix queue directory", but it 
seems that /any/ pathname, absolute or not, does this.


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Matus UHLAR - fantomas via Postfix-users]

On 29.06.24 14:09, Curtis J Blank via Postfix-users wrote:

Oh. I thought I would see them like I see these 10025 entries:

Jun 29 00:00:02 cjbnew postfix/smtp[15813]: < 
127.0.0.1[127.0.0.1]:10025: 220 filter.mynetwork.local ESMTP
including the port number. I added your suggestion and I see the 
traffic now for spampd but 10026 is not mentioned in those log 
entries.


Just saying looks like my expectations were off...


Jyst FYI I use amavisd as content_filter which results into messages like 
this:


Jul  1 00:10:09 mail postfix/lmtp[10512]: 4WC3JH6JvyzFpYN: 
 to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.5, 
 delays=0.06/0.01/0.01/1.4, dsn=2.0.0, status=sent (250 2.0.0 from 
 MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4WC3JK2GyLzFpYh)



where the:
"250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4WC3JK2GyLzFpYh" 
is message from amavis and further the:

"250 2.0.0 Ok: queued as 4WC3JK2GyLzFpYh"
is message from postfix on port 10025, which I further see as:

Jul  1 00:10:09 mail postfix/smtpd[10522]: 4WC3JK2GyLzFpYh: 
client=localhost[127.0.0.1]

...because I did not override syslog_name (didn't need that).


So, if you expect the port_name in logs, it must be send by your spampd and 
if it's not, you won't find it anywhere, which is why I recommended 
overriding syslog_name in master.cf



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: how to reject a domain delivery

[Corey Hickman via Postfix-users]

that's the nice solution. thanks.


> 
> Corey Hickman via Postfix-users:
> 
> > 
> > Hello
> > 
> >  
> > 
> >  I have basic postfix/dovecot installation.
> > 
> >  How can I setup postfix or dovecot to reject the specified domain in 
> > sender?
> > 
> >  I know I can setup sieve script to discard messages from that
> > 
> >  domain, but this method sounds rather rigid.
> > 
> 
> If the list is short, it can go in main.cf:
> 
> /etc/postfix/main.cf:
> 
>  smtpd_sender_restrictions = inline:{
> 
>  { example.com = reject }
> 
>  { other.example = reject} }
> 
> Otherwise some external file will do:
> 
> /etc/postfix/main.cf:
> 
>  smtpd_sender_restrictions = hash:/etc/postfix/sender-access
> 
> /etc/postfix/sender-access:
> 
>  example.com reject
> 
>  other.example reject
> 
> Run "postmap /etc/postfix/sender-access" after editing the file.
> 
> > 
> > Or shall I install rspamd etc to make a reject policy for that?
> > 
> 
> That would work too, as long as rspamd etc care called from a Postfix
> 
> SMTP daemon that receives mail directly from the network (not from
> 
> a Postfix SMTP daemon that receives mail from a content filter).
> 
>  Wietse
> 
> ___
> 
> 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: how to reject a domain delivery

[Wietse Venema via Postfix-users]

Corey Hickman via Postfix-users:
> Hello
> 
> I have basic postfix/dovecot installation.
> How can I setup postfix or dovecot to reject the specified domain in sender?
> I know I can setup sieve script to discard messages from that
> domain, but this method sounds rather rigid.

If the list is short, it can go in main.cf:

/etc/postfix/main.cf:
smtpd_sender_restrictions = inline:{
{ example.com = reject }
{ other.example = reject} }

Otherwise some external file will do:

/etc/postfix/main.cf:
   smtpd_sender_restrictions = hash:/etc/postfix/sender-access

/etc/postfix/sender-access:
example.com reject
other.example reject

Run "postmap /etc/postfix/sender-access" after editing the file.

> Or shall I install rspamd etc to make a reject policy for that?

That would work too, as long as rspamd etc care called from a Postfix
SMTP daemon that receives mail directly from the network (not from
a Postfix SMTP daemon that receives mail from a content filter).

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

[pfx] how to reject a domain delivery

[Corey Hickman via Postfix-users]

Hello

I have basic postfix/dovecot installation.
How can I setup postfix or dovecot to reject the specified domain in sender?
I know I can setup sieve script to discard messages from that domain, but this 
method sounds rather rigid.

Or shall I install rspamd etc to make a reject policy for that?

Thanks & regards.
Corey H
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

Oh. I thought I would see them like I see these 10025 entries:

Jun 29 00:00:02 cjbnew postfix/smtp[15813]: < 
127.0.0.1[127.0.0.1]:10025: 220 filter.mynetwork.local ESMTP


including the port number. I added your suggestion and I see the traffic 
now for spampd but 10026 is not mentioned in those log entries.


Just saying looks like my expectations were off...

On 6/29/24 11:59, Matus UHLAR - fantomas via Postfix-users wrote:

On 29.06.24 10:28, Curtis J Blank via Postfix-users wrote:
I meant to mention I do not see any connections/traffic on port 10026 
in the mail logs.


see how?

You haven't overridden the syslog_name in smtpd options on port 10026.
The logs in your original mail:

Jun 27 00:00:01 cjbnew*mydomain postfix/smtpd[20770]: connect from 
localhost[::1]


are mostly related to port 10026.

Add " -o syslog_name=postfix/spampd-in" to master.cf options to see them


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Matus UHLAR - fantomas via Postfix-users]

On 29.06.24 10:28, Curtis J Blank via Postfix-users wrote:
I meant to mention I do not see any connections/traffic on port 10026 
in the mail logs.


see how?

You haven't overridden the syslog_name in smtpd options on port 10026.
The logs in your original mail:

Jun 27 00:00:01 cjbnew*mydomain postfix/smtpd[20770]: connect from 
localhost[::1]


are mostly related to port 10026.

Add " -o syslog_name=postfix/spampd-in" to master.cf options to see them

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fighting for peace is like fucking for virginity...
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

I meant to mention I do not see any connections/traffic on port 10026 in 
the mail logs.


-Curt

On 6/29/24 10:21, Curtis J Blank via Postfix-users wrote:



On 6/29/24 04:01, Matus UHLAR - fantomas via Postfix-users wrote:

On 29.06.24 01:41, Curtis J Blank via Postfix-users wrote:
No I am not confusing inbound and outbound 


not you, someone other perhaps :-)

and for this I'm only concerned about inbound and actually only on 
ports 10024-26 that are for lack of a better way to put it a 
customization.



:10026 inet  n   -   n -   10  smtpd

...

    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8


This is the problem, together with setting spampd to deliver to 
"localhost".


This causes acept mail on port 10026, both ipv4 and ipv6 (when 
inet_protocols set to "all") but if spampd is set to deliver to 
"localhost" and uses ipv6, all the recipients are rejected because 
ipv6 localhost is not in mynetworks.


if you want this settings work with ipv6 too, you must add [::1] to 
mynetworks:



    -o mynetworks=127.0.0.0/8,[::1]


I do not necessarily want it to work with ::1, this is how spampd is 
current running:


SPAMPD_OPTIONS="--host=127.0.0.1:10025 --relayhost=127.0.0.1:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


-Curt
___
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: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

On 6/29/24 09:38, Bill Cole via Postfix-users wrote:

On 2024-06-28 at 23:45:33 UTC-0400 (Fri, 28 Jun 2024 22:45:33 -0500)
Curtis J Blank via Postfix-users 
is rumored to have said:

OK I tired this. What "mydestination" is set to does not matter 
whether it's localhost or 127.0.0.1 if spampd is set to use localhost 
and not 127.0.0.1 it will not work.


So I'm convinced that was the root cause of my problem, spampd set to 
use localhost when postfix is set to use 127.0.01 explicitly.


If anyone can explain the detailed why I am curious to know.


It's fairly simple: *anywhere* you configure a loopback in the modern 
world, you need to use the same way of doing it, and sticking with a 
loopback IP instead of "localhost" is the best approach because 
different software (e.g. spampd and Postfix) may resolve the name 
differently to only either a v4 or v6 address. Generally speaking, 
when configuring any listener, using an explicit address is the best 
approach because that way you don't have the potential for the name 
being resolved in unexpected ways



Thanks. That is what I did with postfix's conf and now with spampd's config.

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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

On 6/29/24 08:40, Ralph Seichter via Postfix-users wrote:

* Curtis J. Blank via Postfix-users:


Everything except this that is:
mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain

Should this be set to:
mydestination = $myhostname, 127.0.0.1.$mydomain, $mydomain, www.$mydomain

To keep ::1 from being used?

No, that is not what 'mydestination' governs. In the above setting
localhost is a string literal, so it means

   mydestination = ... localhost.example.com ...

after variable expansion. That tells Postfix that recipients like
j...@localhost.example.com designate "local delivery addresses." The
Postfix documentation explains this better and in more detail, but
changing to 127.0.0.1.example.com won't do you any good.
Thanks. Yeah that is what I found out when I tried it so it is set as it 
was.


-Curt


-Ralph
___
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: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

On 6/29/24 04:01, Matus UHLAR - fantomas via Postfix-users wrote:

On 29.06.24 01:41, Curtis J Blank via Postfix-users wrote:
No I am not confusing inbound and outbound 


not you, someone other perhaps :-)

and for this I'm only concerned about inbound and actually only on 
ports 10024-26 that are for lack of a better way to put it a 
customization.



:10026 inet  n   -   n -   10  smtpd

...

    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8


This is the problem, together with setting spampd to deliver to 
"localhost".


This causes acept mail on port 10026, both ipv4 and ipv6 (when 
inet_protocols set to "all") but if spampd is set to deliver to 
"localhost" and uses ipv6, all the recipients are rejected because 
ipv6 localhost is not in mynetworks.


if you want this settings work with ipv6 too, you must add [::1] to 
mynetworks:



    -o mynetworks=127.0.0.0/8,[::1]


I do not necessarily want it to work with ::1, this is how spampd is 
current running:


SPAMPD_OPTIONS="--host=127.0.0.1:10025 --relayhost=127.0.0.1:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Bill Cole via Postfix-users]

On 2024-06-28 at 23:45:33 UTC-0400 (Fri, 28 Jun 2024 22:45:33 -0500)
Curtis J Blank via Postfix-users 
is rumored to have said:

OK I tired this. What "mydestination" is set to does not matter 
whether it's localhost or 127.0.0.1 if spampd is set to use localhost 
and not 127.0.0.1 it will not work.


So I'm convinced that was the root cause of my problem, spampd set to 
use localhost when postfix is set to use 127.0.01 explicitly.


If anyone can explain the detailed why I am curious to know.


It's fairly simple: *anywhere* you configure a loopback in the modern 
world, you need to use the same way of doing it, and sticking with a 
loopback IP instead of "localhost" is the best approach because 
different software (e.g. spampd and Postfix) may resolve the name 
differently to only either a v4 or v6 address. Generally speaking, when 
configuring any listener, using an explicit address is the best approach 
because that way you don't have the potential for the name being 
resolved in unexpected ways


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Ralph Seichter via Postfix-users]

* Curtis J. Blank via Postfix-users:

> Everything except this that is:
> mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain
>
> Should this be set to:
> mydestination = $myhostname, 127.0.0.1.$mydomain, $mydomain, www.$mydomain
>
> To keep ::1 from being used?

No, that is not what 'mydestination' governs. In the above setting
localhost is a string literal, so it means

  mydestination = ... localhost.example.com ...

after variable expansion. That tells Postfix that recipients like
j...@localhost.example.com designate "local delivery addresses." The
Postfix documentation explains this better and in more detail, but
changing to 127.0.0.1.example.com won't do you any good.

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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Matus UHLAR - fantomas via Postfix-users]

On 29.06.24 01:41, Curtis J Blank via Postfix-users wrote:
No I am not confusing inbound and outbound 


not you, someone other perhaps :-)

and for this I'm only 
concerned about inbound and actually only on ports 10024-26 that are 
for lack of a better way to put it a customization.



:10026 inet  n   -   n   -   10  smtpd

...

    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8


This is the problem, together with setting spampd to deliver to "localhost".

This causes acept mail on port 10026, both ipv4 and ipv6 (when 
inet_protocols set to "all") but if spampd is set to deliver to "localhost" 
and uses ipv6, all the recipients are rejected because ipv6 localhost is not 
in mynetworks.


if you want this settings work with ipv6 too, you must add [::1] to 
mynetworks:



    -o mynetworks=127.0.0.0/8,[::1]


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

No I am not confusing inbound and outbound and for this I'm only 
concerned about inbound and actually only on ports 10024-26 that are for 
lack of a better way to put it a customization.


-Curt

postconf -Mf
smtp   inet  n   -   n   -   -   smtpd
submission inet  n   -   n   -   -   smtpd
    -o syslog_name=postfix/submission
    -o smtpd_tls_security_level=encrypt
    -o smtpd_sasl_auth_enable=yes
pickup fifo  n   -   n   60  1   pickup
cleanup    unix  n   -   n   -   0   cleanup
qmgr   fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewrite    unix  -   -   n   -   - trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discard    unix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtual    unix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
postlog    unix-dgram n  -   n   -   1   postlogd
scan   unix  -   -   n   -   10  smtp
:10026 inet  n   -   n   -   10  smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o myhostname=filter.mynetwork.local
    -o smtpd_helo_restrictions=
    -o smtpd_client_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o smtpd_use_tls=no
    -o smtp_use_tls=no
spamtnsp   unix  -   n   n   -   -   local
    -o alias_maps=lmdb:/etc/aliaases


On 6/29/24 01:26, Peter via Postfix-users wrote:

On 29/06/24 18:09, Curtis J Blank via Postfix-users wrote:
I don't know how  many times now I have said this but I will day it 
again.


I have postfix set up to only listen on/use  127.0.0.1 *not* ::1.


What postfix listens on is irrelevant, this has to do with which IP 
postfix connects to spampd with.


And. I am not using spamd, it listens on port 783. I am using spampd 
which shows up as perl because is it written in perl and it listens 
on 10025.


Okay, but that does not change things.


Here is the proof:

new:/etc/postfix # netstat -putan |grep -e ^Active -e ^Proto -e 
127\.0\.0\.1\: -e \:\:1\:


This shows nothing of interest, except that perl is only listening on 
127.0.0.1 which we already knew because you changed that setting just 
now.



Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State 
PID/Program name

tcp    0  0 127.0.0.1:631   0.0.0.0:* LISTEN 2360/cupsd
tcp    0  0 127.0.0.1:783   0.0.0.0:* LISTEN 2441/spamd
tcp    0  0 127.0.0.1:10024 0.0.0.0:* LISTEN 
5063/amavisd (maste

tcp    0  0 127.0.0.1:10025 0.0.0.0:* LISTEN 13980/perl
tcp6   0  0 ::1:783 :::* LISTEN 2441/spamd
tcp6   0  0 ::1:631 :::* LISTEN 2360/cupsd
tcp6   0  0 ::1:10024   :::* LISTEN 5063/amavisd 
(maste

udp    0  0 127.0.0.1:323 0.0.0.0:* 2399/chronyd
udp    0  0 127.0.0.1:659 0.0.0.0:* 2580/rpc.statd
udp6   0  0 ::1:323 :::* 2399/chronyd
new:/etc/postfix #

So you said " Ideally you want to either configure postfix to never 
try to connect to ::1 (but only connect to 127.0.0.1)".


That is one of two possible solutions that I proposed.

That is what I want and I've been saying all along that that is how I 
have it configured. Unless I'm totally not understanding something 
here...


You are confusing outbound connections with inbound (listening) 
connections.  You are also confusing what different settings do. It is 
obvious that postfix is configured to connect to ::1 because it *is* 
attempting to connect to ::1.  Postfix does not go against its 
configuration.



content_filter = scan:[127.0.0.1]:10025


This is the setting that controls the connection, but it's connecting 
through the scan: service which is defined in 

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Peter via Postfix-users]

On 29/06/24 18:09, Curtis J Blank via Postfix-users wrote:

I don't know how  many times now I have said this but I will day it again.

I have postfix set up to only listen on/use  127.0.0.1 *not* ::1.


What postfix listens on is irrelevant, this has to do with which IP 
postfix connects to spampd with.


And. I am not using spamd, it listens on port 783. I am using spampd 
which shows up as perl because is it written in perl and it listens on 
10025.


Okay, but that does not change things.


Here is the proof:

new:/etc/postfix # netstat -putan |grep -e ^Active -e ^Proto -e 
127\.0\.0\.1\: -e \:\:1\:


This shows nothing of interest, except that perl is only listening on 
127.0.0.1 which we already knew because you changed that setting just now.



Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State 
PID/Program name

tcp    0  0 127.0.0.1:631   0.0.0.0:* LISTEN 2360/cupsd
tcp    0  0 127.0.0.1:783   0.0.0.0:* LISTEN 2441/spamd
tcp    0  0 127.0.0.1:10024 0.0.0.0:* LISTEN 
5063/amavisd (maste

tcp    0  0 127.0.0.1:10025 0.0.0.0:* LISTEN 13980/perl
tcp6   0  0 ::1:783 :::* LISTEN  2441/spamd
tcp6   0  0 ::1:631 :::* LISTEN  2360/cupsd
tcp6   0  0 ::1:10024   :::* LISTEN 5063/amavisd (maste
udp    0  0 127.0.0.1:323 0.0.0.0:* 2399/chronyd
udp    0  0 127.0.0.1:659 0.0.0.0:* 2580/rpc.statd
udp6   0  0 ::1:323 :::* 2399/chronyd
new:/etc/postfix #

So you said " Ideally you want to either configure postfix to never try 
to connect to ::1 (but only connect to 127.0.0.1)".


That is one of two possible solutions that I proposed.

That is what I want and I've been saying all along that that is how I 
have it configured. Unless I'm totally not understanding something here...


You are confusing outbound connections with inbound (listening) 
connections.  You are also confusing what different settings do.  It is 
obvious that postfix is configured to connect to ::1 because it *is* 
attempting to connect to ::1.  Postfix does not go against its 
configuration.



content_filter = scan:[127.0.0.1]:10025


This is the setting that controls the connection, but it's connecting 
through the scan: service which is defined in master.cf.  As previously 
requested, please show the output of:


postconf -Mf


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

I don't know how  many times now I have said this but I will day it again.

I have postfix set up to only listen on/use  127.0.0.1 *not* ::1.

And. I am not using spamd, it listens on port 783. I am using spampd 
which shows up as perl because is it written in perl and it listens on 
10025.


Here is the proof:

new:/etc/postfix # netstat -putan |grep -e ^Active -e ^Proto -e 
127\.0\.0\.1\: -e \:\:1\:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
tcp    0  0 127.0.0.1:631   0.0.0.0:* LISTEN  
2360/cupsd
tcp    0  0 127.0.0.1:783   0.0.0.0:* LISTEN  
2441/spamd
tcp    0  0 127.0.0.1:10024 0.0.0.0:* LISTEN  
5063/amavisd (maste
tcp    0  0 127.0.0.1:10025 0.0.0.0:* LISTEN  
13980/perl

tcp6   0  0 ::1:783 :::* LISTEN  2441/spamd
tcp6   0  0 ::1:631 :::* LISTEN  2360/cupsd
tcp6   0  0 ::1:10024   :::* LISTEN  
5063/amavisd (maste
udp    0  0 127.0.0.1:323 0.0.0.0:*   
2399/chronyd
udp    0  0 127.0.0.1:659 0.0.0.0:*   
2580/rpc.statd
udp6   0  0 ::1:323 :::*    
2399/chronyd

new:/etc/postfix #

So you said " Ideally you want to either configure postfix to never try 
to connect to ::1 (but only connect to 127.0.0.1)".


That is what I want and I've been saying all along that that is how I 
have it configured. Unless I'm totally not understanding something here...


-Curt

# postconf -n
alias_maps = lmdb:/etc/aliases
biff = no
canonical_maps = lmdb:/etc/postfix/canonical
command_directory = /usr/sbin
compatibility_level = 3.9
content_filter = scan:[127.0.0.1]:10025
daemon_directory = /usr/lib/postfix/bin/
data_directory = /var/lib/postfix
debug_peer_level = 2
debug_peer_list = 0.0.0.0/0
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5

defer_transports =
delay_warning_time = 1h
disable_mime_output_conversion = no
disable_vrfy_command = yes
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_interfaces = all
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 0
mailbox_transport =
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
masquerade_classes = envelope_sender, header_sender, header_recipient
masquerade_domains = 
masquerade_exceptions = root
message_size_limit = 0
message_strip_characters = \0
mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain
mydomain = mydomain.com
myhostname = mydomain.com
mynetworks_style = host
myorigin = mydomain.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relay_clientcerts = lmdb:/etc/postfix/relay_ccerts
relay_domains = $mydestination lmdb:/etc/postfix/relay
relayhost =
relocated_maps = lmdb:/etc/postfix/relocated
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sender_canonical_maps = lmdb:/etc/postfix/sender_canonical
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_dns_support_level = enabled
smtp_enforce_tls = no
smtp_sasl_auth_enable = no
smtp_sasl_password_maps =
smtp_sasl_security_options =
smtp_tls_CAfile =
smtp_tls_CApath =
smtp_tls_cert_file =
smtp_tls_key_file =
smtp_tls_security_level =
smtp_tls_session_cache_database =
smtp_use_tls = no
smtpd_banner = $myhostname ESMTP
smtpd_client_restrictions = permit_sasl_authenticated, 
permit_mynetworks,reject

smtpd_delay_reject = yes
smtpd_discard_ehlo_keyword_address_maps = 
cidr:/etc/postfix/discard_ehlo_keyword

smtpd_enforce_tls = no
smtpd_forbid_bare_newline = normalize
smtpd_forbid_bare_newline_exclusions = $mynetworks
smtpd_helo_required = no
smtpd_helo_restrictions =
smtpd_recipient_restrictions = permit_tls_clientcerts, 
permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = 
smtpd_sasl_path = smtpd
smtpd_sasl_type = cyrus
smtpd_sender_restrictions = lmdb:/etc/postfix/access, 
check_sender_access lmdb:/etc/postfix/sender_access, check_sender_access 
regexp:/etc/postfix/sender_access_regex, reject_unknown_sender_domain, 
reject_unverified_sender

smtpd_tls_CAfile = /etc/mail/certs/CA.cert.pem
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_ask_ccert = yes
smtpd_tls_cert_file = /etc/mail/certs/MYServer.cert.pem
smtpd_tls_exclude_ciphers = RC4
smtpd_tls_key_file = /etc/mail/certs/MYServer.key.pem
smtpd_tls_received_header = yes
smtpd_tls_security_level =
smtpd_use_tls = yes
strict_8bitmime = no
strict_rfc821_envelopes = no
transport_maps = lmdb:/etc/postfix/transport
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Peter via Postfix-users]

On 29/06/24 15:16, Curtis J Blank via Postfix-users wrote:
Peter, my  misunderstanding, sorry. This is what I discovered today in 
my testing. I explicitly used 127.0.0.1 and not localhost or so I 
thought, I explain that below.


Back on topic. I did some more testing. This was the spampd options used:
SPAMPD_OPTIONS="--host=localhost:10025 --relayhost=localhost:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


I changed it to:
SPAMPD_OPTIONS="--host=127.0.0.1:10025 --relayhost=127.0.0.1:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


This would work, kind of, but not the way that you think, see below.


There is no global
mynetworks = something
in  main.cf.


mynetworks is immaterial to this, it has nothing to do with this issue.


inet_protocols was set back to:
inet_protocols = all

And all works just fine. So, spampd set to use localhost when everything 
in postfix was set to use 127.0.0.1 probably explains why smtp thought 
spampd was trying to relay via a ::1 connection and denied it.


So the change you made to spamd changed it so that it no longer listens 
on ::1 but rather it now just listens on 127.0.0.1, before it was 
listening on both (being set to localhost).  There is another setting 
which you have set to 127.0.0.1 which controls which connections spamd 
will accept mail from, this is not the same setting as the one you just 
changed.


So before you had spamd listening on both 127.0.0.1 and on ::1 but only 
accepting mail from 127.0.0.1, so if postfix tried to connect from 
127.0.0.1 spamd would be happy, but if postfix tried to connect from ::1 
spamd would answer the connection (because it's listening) allow postfix 
to continue with the RCPT TO stage and then reject the message with a 
454 relay access denied response, this causes Postfix to defer the 
connection and retry it at a later time, and when it retries there is a 
good chance it will try ::1 again.  So Postfix sees a good connection 
but the spamd is deferring the message.


So what is likely happening now is Postfix still attempts to connect to 
::1 (because you didn't change the postfix settings in this regard) but 
spamd is no longer listening on ::1 so postfix cannot connect at all. 
Postfix seeing this then immediately tries to connect to 127.0.0.1 and 
is able to connect to spamd and relay the message.  So Postfix is still 
configured to connect to the wrong IP but because spamd isn't even 
listening on that IP address at all postfix tries the next possibility 
which is the correct IP and it does so right away because there is no 
deferral.


Note that this is not the most ideal way of solving the problem. 
Ideally you want to either configure postfix to never try to connect to 
::1 (but only connect to 127.0.0.1) or you want to configure spamd both 
listen and accept messages on both ::1 and 127.0.0.1.  This way there 
should never even be an attempt to connect to a non-working address 
(unless spamd actually is down).


But the 
part I still don't understand is why smtp was trying to use ::1 when 
everything postfix wise is set to use 127.0.0.1.


To answer that I would need to see your config, specifically the output 
of the two commands I gave you before.



Everything except this that is:
mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain

Should this be set to:
mydestination = $myhostname, 127.0.0.1.$mydomain, $mydomain, www.$mydomain


mydestination has nothing to do with this issue.

To keep ::1 from being used? If so oversight on my part, not thinking 
that through, so setting it to 127.0.0.1 would probably allow me to 
revert the spamd options back to what they were.


Maybe I'll just try it and see.


Send your config.


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

OK I tired this. What "mydestination" is set to does not matter whether 
it's localhost or 127.0.0.1 if spampd is set to use localhost and not 
127.0.0.1 it will not work.


So I'm convinced that was the root cause of my problem, spampd set to 
use localhost when postfix is set to use 127.0.01 explicitly.


If anyone can explain the detailed why I am curious to know.

Thanks,

-Curt

On 6/28/24 22:16, Curtis J Blank via Postfix-users wrote:
Peter, my  misunderstanding, sorry. This is what I discovered today in 
my testing. I explicitly used 127.0.0.1 and not localhost or so I 
thought, I explain that below.


Back on topic. I did some more testing. This was the spampd options used:
SPAMPD_OPTIONS="--host=localhost:10025 --relayhost=localhost:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


I changed it to:
SPAMPD_OPTIONS="--host=127.0.0.1:10025 --relayhost=127.0.0.1:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


There is no global
mynetworks = something
in  main.cf.

inet_protocols was set back to:
inet_protocols = all

And all works just fine. So, spampd set to use localhost when 
everything in postfix was set to use 127.0.0.1 probably explains why 
smtp thought spampd was trying to relay via a ::1 connection and 
denied it. But the part I still don't understand is why smtp was 
trying to use ::1 when everything postfix wise is set to use 127.0.0.1.


Everything except this that is:
mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain

Should this be set to:
mydestination = $myhostname, 127.0.0.1.$mydomain, $mydomain, www.$mydomain

To keep ::1 from being used? If so oversight on my part, not thinking 
that through, so setting it to 127.0.0.1 would probably allow me to 
revert the spamd options back to what they were.


Maybe I'll just try it and see.

-Curt

On 6/28/24 21:01, Peter via Postfix-users wrote:

On 29/06/24 03:17, Curtis J Blank via Postfix-users wrote:
Well Peter all the "mynetworks =" that I have defined explicitly 
state 127.0.0.1 not localhost and all the logging shows 127.0.0.1 
not localhost. So that is why I say I am using 127.0.0.1. So I 
cannot follow Ralph's suggestion changing localhost to 127.0.0.1 
because there are no localhost's used in the configs to change.


I never said the problem was with mynetworks, and neither did Ralph. 
Someone else said that and it's incorrect.  The problem is with 
whatever setting you have pointing to localhost:10025 as per your 
initial email:


"The problem was handing messages off to localhost:10025 for 
spamassassin to scan before delivery"


...this is likely your content_filter setting but could be done in 
other settings instead.


Also, smtp_address_preference is not set to anything on the old 
server, it is set to "any" in the new server and I think you hit on 
the why I was looking for, thank you. Wonder if the default setting 
in 2.11 is ipv4 and not "any".


The default in 2.11 is any and any is probably the best setting under 
most circumstances, except it will cause some attempts to be made to 
ipv6 and some to ipv4, so you'd get ransom rejections based on which 
is tried first.


I was not aware of that parameter until you mentioned it and things 
like that are exactly why I started this thread.


And I don't have compatibility_level set in the old sever either, it 
is set to 3.9 in the new server. Another one I was not aware of.


3.9 is where you want it set.

Even though I did a line by line config comparison I glossed over 
things that weren't in the old and the new. I see in this case that 
was a mistake, those parameters by name are enough to clue me in. I 
will look to see what SA is set to use but I bet you're right.


Again, thanks all, this really helps and I'm bet'n I'll be able to 
set "inet_protocols = all" shortly.


You should either explicitly set [127.0.0.1]:10025 for your 
content_filter (or whatever setting you're using for that) or set 
your SpamAssassin config to accept the mail on both 127.0.0.1 and 
::1. either of these whould work and are probably the best 
recommendation I can give for a fix.



Peter
___
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 topostfix-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: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

Yeah I thought of including the config but that OP was long due to all 
the logging so I didn't want to make it longer. I did say in my OP I 
would provide anything if requested.


-Curt

On 6/28/24 21:11, Peter via Postfix-users wrote:

On 29/06/24 05:59, Curtis J Blank via Postfix-users wrote:
Always in a good mood. It's a waste not to be. When I'm focused on 
something I just state the facts as I understand them and sometimes 
that doesn't come across well.


Yeah I know localhost can be either that's why I used 127.0.0.1 in 
the config and don't/didn't use localhost anywhere, as I later stated.


I errored in my OP by not making that clear and using the word 
localhost. But to me localhost is 127.0.0.1, I don't even think about 
::1 as far as localhost goes. I know I should. So that is why I can't 
understand why ::1:10025 was being used to do the SA connection and I 
still need to determine that why.


We went by what you said in your OP.  You never did post your config. 
It would help a great deal if you would post the output of:


postconf -nf; postconf -Mf


Peter
___
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: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

Peter, my  misunderstanding, sorry. This is what I discovered today in 
my testing. I explicitly used 127.0.0.1 and not localhost or so I 
thought, I explain that below.


Back on topic. I did some more testing. This was the spampd options used:
SPAMPD_OPTIONS="--host=localhost:10025 --relayhost=localhost:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


I changed it to:
SPAMPD_OPTIONS="--host=127.0.0.1:10025 --relayhost=127.0.0.1:10026 
--user=vscan --tagall --children=5 --maxsize=7168 --homedir=/home/vscan"


There is no global
mynetworks = something
in  main.cf.

inet_protocols was set back to:
inet_protocols = all

And all works just fine. So, spampd set to use localhost when everything 
in postfix was set to use 127.0.0.1 probably explains why smtp thought 
spampd was trying to relay via a ::1 connection and denied it. But the 
part I still don't understand is why smtp was trying to use ::1 when 
everything postfix wise is set to use 127.0.0.1.


Everything except this that is:
mydestination = $myhostname, localhost.$mydomain, $mydomain, www.$mydomain

Should this be set to:
mydestination = $myhostname, 127.0.0.1.$mydomain, $mydomain, www.$mydomain

To keep ::1 from being used? If so oversight on my part, not thinking 
that through, so setting it to 127.0.0.1 would probably allow me to 
revert the spamd options back to what they were.


Maybe I'll just try it and see.

-Curt

On 6/28/24 21:01, Peter via Postfix-users wrote:

On 29/06/24 03:17, Curtis J Blank via Postfix-users wrote:
Well Peter all the "mynetworks =" that I have defined explicitly 
state 127.0.0.1 not localhost and all the logging shows 127.0.0.1 not 
localhost. So that is why I say I am using 127.0.0.1. So I cannot 
follow Ralph's suggestion changing localhost to 127.0.0.1 because 
there are no localhost's used in the configs to change.


I never said the problem was with mynetworks, and neither did Ralph. 
Someone else said that and it's incorrect.  The problem is with 
whatever setting you have pointing to localhost:10025 as per your 
initial email:


"The problem was handing messages off to localhost:10025 for 
spamassassin to scan before delivery"


...this is likely your content_filter setting but could be done in 
other settings instead.


Also, smtp_address_preference is not set to anything on the old 
server, it is set to "any" in the new server and I think you hit on 
the why I was looking for, thank you. Wonder if the default setting 
in 2.11 is ipv4 and not "any".


The default in 2.11 is any and any is probably the best setting under 
most circumstances, except it will cause some attempts to be made to 
ipv6 and some to ipv4, so you'd get ransom rejections based on which 
is tried first.


I was not aware of that parameter until you mentioned it and things 
like that are exactly why I started this thread.


And I don't have compatibility_level set in the old sever either, it 
is set to 3.9 in the new server. Another one I was not aware of.


3.9 is where you want it set.

Even though I did a line by line config comparison I glossed over 
things that weren't in the old and the new. I see in this case that 
was a mistake, those parameters by name are enough to clue me in. I 
will look to see what SA is set to use but I bet you're right.


Again, thanks all, this really helps and I'm bet'n I'll be able to 
set "inet_protocols = all" shortly.


You should either explicitly set [127.0.0.1]:10025 for your 
content_filter (or whatever setting you're using for that) or set your 
SpamAssassin config to accept the mail on both 127.0.0.1 and ::1. 
either of these whould work and are probably the best recommendation I 
can give for a fix.



Peter
___
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: Handing off via localhost:10025 to spamassassin for scanning failure

[Peter via Postfix-users]

On 29/06/24 05:59, Curtis J Blank via Postfix-users wrote:
Always in a good mood. It's a waste not to be. When I'm focused on 
something I just state the facts as I understand them and sometimes that 
doesn't come across well.


Yeah I know localhost can be either that's why I used 127.0.0.1 in the 
config and don't/didn't use localhost anywhere, as I later stated.


I errored in my OP by not making that clear and using the word 
localhost. But to me localhost is 127.0.0.1, I don't even think about 
::1 as far as localhost goes. I know I should. So that is why I can't 
understand why ::1:10025 was being used to do the SA connection and I 
still need to determine that why.


We went by what you said in your OP.  You never did post your config. 
It would help a great deal if you would post the output of:


postconf -nf; postconf -Mf


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Peter via Postfix-users]

On 29/06/24 03:17, Curtis J Blank via Postfix-users wrote:
Well Peter all the "mynetworks =" that I have defined explicitly state 
127.0.0.1 not localhost and all the logging shows 127.0.0.1 not 
localhost. So that is why I say I am using 127.0.0.1. So I cannot follow 
Ralph's suggestion changing localhost to 127.0.0.1 because there are no 
localhost's used in the configs to change.


I never said the problem was with mynetworks, and neither did Ralph. 
Someone else said that and it's incorrect.  The problem is with whatever 
setting you have pointing to localhost:10025 as per your initial email:


"The problem was handing messages off to localhost:10025 for 
spamassassin to scan before delivery"


...this is likely your content_filter setting but could be done in other 
settings instead.


Also, smtp_address_preference is not set to anything on the old server, 
it is set to "any" in the new server and I think you hit on the why I 
was looking for, thank you. Wonder if the default setting in 2.11 is 
ipv4 and not "any".


The default in 2.11 is any and any is probably the best setting under 
most circumstances, except it will cause some attempts to be made to 
ipv6 and some to ipv4, so you'd get ransom rejections based on which is 
tried first.


I was not aware of that parameter until you 
mentioned it and things like that are exactly why I started this thread.


And I don't have compatibility_level set in the old sever either, it is 
set to 3.9 in the new server. Another one I was not aware of.


3.9 is where you want it set.

Even though I did a line by line config comparison I glossed over things 
that weren't in the old and the new. I see in this case that was a 
mistake, those parameters by name are enough to clue me in. I will look 
to see what SA is set to use but I bet you're right.


Again, thanks all, this really helps and I'm bet'n I'll be able to set 
"inet_protocols = all" shortly.


You should either explicitly set [127.0.0.1]:10025 for your 
content_filter (or whatever setting you're using for that) or set your 
SpamAssassin config to accept the mail on both 127.0.0.1 and ::1. 
either of these whould work and are probably the best recommendation I 
can give for a fix.



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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

A bit off topic but it just happened to dawn on me that that Ethernet 
Tap I referred to was a H4000. My brain works that way. Just to see if 
my memory hadn't failed me I googled it. Yep H4000. And I even found a 
Wiki page on it with a picture of the backbone cable and the H4000. And 
the tool to drill the hole in the cable. When the DESTA came out and you 
could use Thinwire (coax) that was a revolution!. Yes I'm old. LOL


https://gunkies.org/wiki/DEC_Ethernet_Transceivers

On 6/28/24 12:59, Curtis J Blank via Postfix-users wrote:
Always in a good mood. It's a waste not to be. When I'm focused on 
something I just state the facts as I understand them and sometimes 
that doesn't come across well.


Yeah I know localhost can be either that's why I used 127.0.0.1 in the 
config and don't/didn't use localhost anywhere, as I later stated.


I errored in my OP by not making that clear and using the word 
localhost. But to me localhost is 127.0.0.1, I don't even think about 
::1 as far as localhost goes. I know I should. So that is why I can't 
understand why ::1:10025 was being used to do the SA connection and I 
still need to determine that why.


I got my first computer at home in the late 70's. I cut my teeth on 
networking back in '79 on DECNET where Ethernet was a huge thick cable 
that you used a tool to drill a hole in and mount a Tap as it was 
called to branch off that backbone.


TCP/IP was in it's infancy too at the time. That was over 30 years 
before ipv6 was around so localhost was 127.0.0.1 and now to me, oh 
yeah, ::1 is too now.


-Curt

On 6/28/24 12:09, Ralph Seichter via Postfix-users wrote:

* Curtis J. Blank via Postfix-users:


What I am looking for is pretty simple. How to get it to work with
"inet_protocols = all" like my existing server is currently set up 
to do

and not be limited to ipv4 only.

Well, you seem to be in a good mood. ;-)


And it is already set to use 127.0.0.1 so why it is using [::1] instead
when the old server uses 127.0.01, that is part of the mystery. The
configs are exactly the same yet they operate differently.

Like I wrote, localhost is not the same as 127.0.0.1 or ::1. It is just
a name that your server needs to resolve into an IP address, which is a
possible source of two servers behaving differently. If you explicitly
use IP addresses instead of localhost in your configuration (Postfix,
SpamAssassin, etc., both for binding and connecting), as I suggested,
you can avoid DNS related problems. This technique was old 20 years ago,
but it still works today.

-Ralph
___
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

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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

Always in a good mood. It's a waste not to be. When I'm focused on 
something I just state the facts as I understand them and sometimes that 
doesn't come across well.


Yeah I know localhost can be either that's why I used 127.0.0.1 in the 
config and don't/didn't use localhost anywhere, as I later stated.


I errored in my OP by not making that clear and using the word 
localhost. But to me localhost is 127.0.0.1, I don't even think about 
::1 as far as localhost goes. I know I should. So that is why I can't 
understand why ::1:10025 was being used to do the SA connection and I 
still need to determine that why.


I got my first computer at home in the late 70's. I cut my teeth on 
networking back in '79 on DECNET where Ethernet was a huge thick cable 
that you used a tool to drill a hole in and mount a Tap as it was called 
to branch off that backbone.


TCP/IP was in it's infancy too at the time. That was over 30 years 
before ipv6 was around so localhost was 127.0.0.1 and now to me, oh 
yeah, ::1 is too now.


-Curt

On 6/28/24 12:09, Ralph Seichter via Postfix-users wrote:

* Curtis J. Blank via Postfix-users:


What I am looking for is pretty simple. How to get it to work with
"inet_protocols = all" like my existing server is currently set up to do
and not be limited to ipv4 only.

Well, you seem to be in a good mood. ;-)


And it is already set to use 127.0.0.1 so why it is using [::1] instead
when the old server uses 127.0.01, that is part of the mystery. The
configs are exactly the same yet they operate differently.

Like I wrote, localhost is not the same as 127.0.0.1 or ::1. It is just
a name that your server needs to resolve into an IP address, which is a
possible source of two servers behaving differently. If you explicitly
use IP addresses instead of localhost in your configuration (Postfix,
SpamAssassin, etc., both for binding and connecting), as I suggested,
you can avoid DNS related problems. This technique was old 20 years ago,
but it still works today.

-Ralph
___
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: Handing off via localhost:10025 to spamassassin for scanning failure

[Ralph Seichter via Postfix-users]

* Curtis J. Blank via Postfix-users:

> What I am looking for is pretty simple. How to get it to work with 
> "inet_protocols = all" like my existing server is currently set up to do 
> and not be limited to ipv4 only.

Well, you seem to be in a good mood. ;-)

> And it is already set to use 127.0.0.1 so why it is using [::1] instead 
> when the old server uses 127.0.01, that is part of the mystery. The 
> configs are exactly the same yet they operate differently.

Like I wrote, localhost is not the same as 127.0.0.1 or ::1. It is just
a name that your server needs to resolve into an IP address, which is a
possible source of two servers behaving differently. If you explicitly
use IP addresses instead of localhost in your configuration (Postfix,
SpamAssassin, etc., both for binding and connecting), as I suggested,
you can avoid DNS related problems. This technique was old 20 years ago,
but it still works today.

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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

Thank you, Alexander, Matus, Jaroslaw, Peter, and Bill, just the kind of 
ideas I was looking for.


My old postfix server is running 2.11 and I have not dealt much with 
postfix really since then because like I said it just worked, did what I 
needed it to do. Currently I'm working with 3.9 and I expected there to 
be changes.


So no I did not validate that spamassassin was using 127.0.01 *and* ::1 
because I was not expecting it too. Like I said the new server is 
configured as a carbon copy of the old server and the old server does 
not use ::1. When I say carbon copy I diff -y the config files and go 
through them line by line.


Yes spamassassin is listening on 10025, amavis on 10024.

netstat -tapn |grep :100
tcp    0  0 127.0.0.1:10024 0.0.0.0:* LISTEN  
4866/amavisd (maste

tcp    0  0 127.0.0.1:10025 0.0.0.0:* LISTEN  4791/perl
tcp    0  0 0.0.0.0:10026   0.0.0.0:* LISTEN  
4952/master

tcp    0  0 :::10026    :::* LISTEN  4952/master

I had not been using a global "mynetworks =" in the old server or the 
new server only using "-o mynetworsk =" where needed and no ::1 was not 
in any of them. Did not need to be because it worked without that on the 
old server. I did try a:

"mynetworks = 127.0.0.0/8, 192.168.0.0/24"
on the new server but that did not fix the problem I was having.

Well Peter all the "mynetworks =" that I have defined explicitly state 
127.0.0.1 not localhost and all the logging shows 127.0.0.1 not 
localhost. So that is why I say I am using 127.0.0.1. So I cannot follow 
Ralph's suggestion changing localhost to 127.0.0.1 because there are no 
localhost's used in the configs to change.


Also, smtp_address_preference is not set to anything on the old server, 
it is set to "any" in the new server and I think you hit on the why I 
was looking for, thank you. Wonder if the default setting in 2.11 is 
ipv4 and not "any". I was not aware of that parameter until you 
mentioned it and things like that are exactly why I started this thread.


And I don't have compatibility_level set in the old sever either, it is 
set to 3.9 in the new server. Another one I was not aware of.


Even though I did a line by line config comparison I glossed over things 
that weren't in the old and the new. I see in this case that was a 
mistake, those parameters by name are enough to clue me in. I will look 
to see what SA is set to use but I bet you're right.


Again, thanks all, this really helps and I'm bet'n I'll be able to set 
"inet_protocols = all" shortly.





On 6/28/24 08:04, Bill Cole via Postfix-users wrote:

On 2024-06-28 at 05:23:27 UTC-0400 (Fri, 28 Jun 2024 11:23:27 +0200)
Matus UHLAR - fantomas via Postfix-users 
is rumored to have said:

Who exactly listens on port 10025? looks like postfix sends mail to 
itself, or is it another postfix instance?


Historically that has been a port commonly used for the SMTP proxy 
form of filtering using Amavis. Since SpamAssassin has no SMTP proxy 
function and his logs show both sides of a SMTP chat between 2 smtpd 
processes, I think Amavis is the most likely thing listening.



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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Bill Cole via Postfix-users]

On 2024-06-28 at 05:23:27 UTC-0400 (Fri, 28 Jun 2024 11:23:27 +0200)
Matus UHLAR - fantomas via Postfix-users 
is rumored to have said:

Who exactly listens on port 10025? looks like postfix sends mail to 
itself, or is it another postfix instance?


Historically that has been a port commonly used for the SMTP proxy form 
of filtering using Amavis. Since SpamAssassin has no SMTP proxy function 
and his logs show both sides of a SMTP chat between 2 smtpd processes, I 
think Amavis is the most likely thing listening.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Roundcube question

[Gary R. Schmidt via Postfix-users]

On 28/06/2024 19:14, Jeff Peng via Postfix-users wrote:
Does one roundcube installation support only one SASL backend? For 
example I configure it to access aol then it cannot access gmail.


Other webmail such as snappy can connect to many smtp/imap backends, 
such as yahoo/outlook/gmail, they can be set up in one installation.



It's all documented in /path/to/roundcube/config/config.inc.php.sample.

And no doubt other places.

Cheers,
GaryB-)

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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Peter via Postfix-users]

On 28/06/24 19:01, Curtis J Blank via Postfix-users wrote:
What I am looking for is pretty simple. How to get it to work with 
"inet_protocols = all" like my existing server is currently set up to do 
and not be limited to ipv4 only.


And it is already set to use 127.0.0.1


No it is not, it is set to use localhost which is very different from 
[127.0.0.1].  If you look at your /etc/hosts file you will find 
localhost entries for both 127.0.0.1 and ::1, so in this case Postfix is 
choosing ::1 over 127.0.0.1


so why it is using [::1] instead 
when the old server uses 127.0.01, that is part of the mystery. The 
configs are exactly the same yet they operate differently.


Either you have an old (2.8 or older) version of postfix, 
smtp_address_preference is set to ipv6, you do not have 
compatibility_level set (or it is set to 0), or your /etc/hosts file 
only has an ipv6 (::1) entry for localhost.  At an educated guess I 
would say that you don't have compatibility_level set and so postfix is 
falling back to the pre-2.8 default for smtp_address_preference which is 
ipv6.


I want to know why. If you don't know and understand the root cause of 
something that is not a good position to be in going forward. Good 
enough is not good enough...


Please re-read what Ralph told you, changing the postfix setting from 
localhost to [127.0.0.1] is a perfectly valid way to resolve the issue 
and that was the suggestion he gave.


Other ways that you can likely resolve the issue:

* Set compatibility_level to 2 or higher (do note that this will affect 
other settings as well).


* Explicitly set smtp_address_preference to ipv4.

Another thing of note, judging from your log entries SpamAssassin is 
listening on both 127.0.0.1 and ::1 but for some reason is rejecting the 
message sent to ::1, but not the one sent to 127.0.0.1.  That is 
something you should check in your SpamAssassin settings.  It is likely 
that you have SA explicitly configured to accept mail from 127.0.0.1 but 
not from ::1, changing that to localhost or to allow both 127.0.0.1 and 
::1 would likely be another way to resolve the issue.



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

[pfx] Re: Roundcube question

[Dimitris via Postfix-users]

Στις 28/6/24 12:14, ο/η Jeff Peng via Postfix-users έγραψε:
Other webmail such as snappy can connect to many smtp/imap backends, 
such as yahoo/outlook/gmail, they can be set up in one installation.


roundcube does the same as snappy , by manually editing config.inc.php 
(iirc). eg...:


$config['smtp_host'] = array(
'mx1' => 'tls://mx1:587',
'mx2' => 'tls://mx2:587',
'mx3' => 'tls://mx3:587');

similar with imap_host...

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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Jaroslaw Rafa via Postfix-users]

Dnia 28.06.2024 o godz. 00:16:31 Curtis J Blank via Postfix-users pisze:
> When "inet_protocols = all" the connection to filter.mynetwork.local
> localhost
> port 10025 to hand off the message to spamassassin for scanning fails with
> "Relay access denied". What I finally noticed is that the connection
> in coming
> from "localhost[::1]" a ipv6 connection.
> 
> So on a long-shot I changed "inet_protocols = ipv4" and then
> delivery worked.

Let me guess: you don't have IPv6 address [::1] in "mynetworks=" ?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"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."
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Matus UHLAR - fantomas via Postfix-users]

On 28.06.24 02:01, Curtis J Blank via Postfix-users wrote:
What I am looking for is pretty simple. How to get it to work with 
"inet_protocols = all" like my existing server is currently set up to 
do and not be limited to ipv4 only.


simply allow receiving messages from ::1 on port 10025.
10025 currently only seems to accept mail from 127.0.0.1.

Who exactly listens on port 10025? looks like postfix sends mail to itself, 
or is it another postfix instance?


And it is already set to use 127.0.0.1 so why it is using [::1] 
instead when the old server uses 127.0.01, that is part of the 
mystery. The configs are exactly the same yet they operate 
differently.


I want to know why. If you don't know and understand the root cause of 
something that is not a good position to be in going forward. Good 
enough is not good enough...


On 6/28/24 00:40, Ralph Seichter via Postfix-users wrote:

* Curtis J. Blank via Postfix-users:


I would like to get some insight as to the cause and correct
configuration to use. [...]

Maybe it is simply too early in the morning for me to get your point,
but what insight are you looking for, exactly?

You already found out that localhost does not necessarily resolve to
127.0.0.1 if both IPv4 and IPv6 are used. That's not a problem. If you
do need to make the distinction, you can be explicit by using either
[127.0.0.1] or [::1] in your settings. Does this help?



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Roundcube question

[Jeff Peng via Postfix-users]

Does one roundcube installation support only one SASL backend? For 
example I configure it to access aol then it cannot access gmail.


Other webmail such as snappy can connect to many smtp/imap backends, 
such as yahoo/outlook/gmail, they can be set up in one installation.


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

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Alexander Leidinger via Postfix-users]

Am 2024-06-28 09:01, schrieb Curtis J Blank via Postfix-users:

What I am looking for is pretty simple. How to get it to work with 
"inet_protocols = all" like my existing server is currently set up to 
do and not be limited to ipv4 only.


And it is already set to use 127.0.0.1 so why it is using [::1] instead 
when the old server uses 127.0.01, that is part of the mystery. The 
configs are exactly the same yet they operate differently.


I want to know why. If you don't know and understand the root cause of 
something that is not a good position to be in going forward. Good 
enough is not good enough...


Did you already validate (netstat -tnl) that spamassassin listens on 
both addresses, 127.0.0.1 and ::1?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

signature.asc
Description: OpenPGP digital signature
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

What I am looking for is pretty simple. How to get it to work with 
"inet_protocols = all" like my existing server is currently set up to do 
and not be limited to ipv4 only.


And it is already set to use 127.0.0.1 so why it is using [::1] instead 
when the old server uses 127.0.01, that is part of the mystery. The 
configs are exactly the same yet they operate differently.


I want to know why. If you don't know and understand the root cause of 
something that is not a good position to be in going forward. Good 
enough is not good enough...


On 6/28/24 00:40, Ralph Seichter via Postfix-users wrote:

* Curtis J. Blank via Postfix-users:


I would like to get some insight as to the cause and correct
configuration to use. [...]

Maybe it is simply too early in the morning for me to get your point,
but what insight are you looking for, exactly?

You already found out that localhost does not necessarily resolve to
127.0.0.1 if both IPv4 and IPv6 are used. That's not a problem. If you
do need to make the distinction, you can be explicit by using either
[127.0.0.1] or [::1] in your settings. Does this help?

-Ralph
___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-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: Handing off via localhost:10025 to spamassassin for scanning failure

[Ralph Seichter via Postfix-users]

* Curtis J. Blank via Postfix-users:

> I would like to get some insight as to the cause and correct 
> configuration to use. [...]

Maybe it is simply too early in the morning for me to get your point,
but what insight are you looking for, exactly?

You already found out that localhost does not necessarily resolve to
127.0.0.1 if both IPv4 and IPv6 are used. That's not a problem. If you
do need to make the distinction, you can be explicit by using either
[127.0.0.1] or [::1] in your settings. Does this help?

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

[pfx] Handing off via localhost:10025 to spamassassin for scanning failure

[Curtis J Blank via Postfix-users]

I would like to get some insight as to the cause and correct 
configuration to use. Building a new server that in part is my postfix 
server and spent the last couple of days pulling my hair out trying to 
get it to deliver mail.


I have an existing postfix server that has been working since 2014 maybe 
even back to 2011. I basically set up this new server exactly how the 
old one is set up. So this is not a newbie asking for help. The fix I 
finally figured out boggles my mind.


The problem was handing messages off to localhost:10025 for spamassassin 
to scan before delivery, every attempt to do so was denied. Below is an 
explanation of what I found what I finally did to get it to work. If 
configs, logs, anything else is needed to diagnose this let me know, 
there's already a lot here so I figured i'd wait before I add more.


When "inet_protocols = all" the connection to filter.mynetwork.local 
localhost

port 10025 to hand off the message to spamassassin for scanning fails with
"Relay access denied". What I finally noticed is that the connection in 
coming

from "localhost[::1]" a ipv6 connection.

So on a long-shot I changed "inet_protocols = ipv4" and then delivery 
worked.


Jun 27 00:00:01 cjbnew*mydomain postfix/smtpd[20766]: connect from 
localhost[::1]
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 220 filter.mynetwork.local ESMTP
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: > 
127.0.0.1[127.0.0.1]:10025: EHLO mydomain.com
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-filter.mynetwork.local
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-PIPELINING
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-SIZE
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-ETRN
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-ENHANCEDSTATUSCODES
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-8BITMIME
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-DSN
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250-SMTPUTF8
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: < 
127.0.0.1[127.0.0.1]:10025: 250 CHUNKING
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: server features: 
0x20900f size 0
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: Using ESMTP 
PIPELINING, TCP send buffer size is 2626560, PIPELINING buffer size is 4096
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: smtp_stream_setup: 
maxtime=300 enable_deadline=0 min_data_rate=0
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: > 
127.0.0.1[127.0.0.1]:10025: MAIL FROM: SIZE=426
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: > 
127.0.0.1[127.0.0.1]:10025: RCPT TO: 
ORCPT=rfc822;bobby@gmail.com
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: > 
127.0.0.1[127.0.0.1]:10025: DATA
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20757]: smtp_stream_setup: 
maxtime=300 enable_deadline=0 min_data_rate=0
Jun 27 00:00:01 cjbnew*mydomain postfix/smtpd[20770]: connect from 
localhost[::1]
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 220 filter.mynetwork.local ESMTP
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: > 
127.0.0.1[127.0.0.1]:10025: EHLO mydomain.com
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-filter.mynetwork.local
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-PIPELINING
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-SIZE
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-ETRN
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-ENHANCEDSTATUSCODES
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-8BITMIME
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-DSN
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250-SMTPUTF8
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: < 
127.0.0.1[127.0.0.1]:10025: 250 CHUNKING
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: server features: 
0x20900f size 0
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: Using ESMTP 
PIPELINING, TCP send buffer size is 2626560, PIPELINING buffer size is 4096
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: smtp_stream_setup: 
maxtime=300 enable_deadline=0 min_data_rate=0
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: > 
127.0.0.1[127.0.0.1]:10025: MAIL FROM: SIZE=417
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: > 
127.0.0.1[127.0.0.1]:10025: RCPT TO: 
ORCPT=rfc822;BobbyJoe@cjbnew
Jun 27 00:00:01 cjbnew*mydomain postfix/smtp[20763]: > 

[pfx] Re: DANE and STS

[Gerd Hoerst via Postfix-users]

Hi !

Sure...    i distribute 3 1 1 and 2 1 1 are onl for backup...

I had the setup with R3 running for years w/o problems  but now i have 
also R11/12/13/14 as backup entries


Ciao gerd

Am 27.06.2024 um 15:34 schrieb Michael Grimm via Postfix-users:

Gerd Hoerst via Postfix-users  wrote:


I checked my cert and it related to R10 , but i will also publish the rest 
regarding you advice

I do recommend investigating '3 1 1' records, instead.

"Hence, my best advice is to not play Let's Encrypt whack-a-mole, and use "3 1 1" 
records with stable keys (not automatically replaced with every renewal)."
[see Viktors link: http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html] 



And have a look at a thread in this ML starting with 
https://www.mail-archive.com/postfix-users@postfix.org/msg92488.html


I have followed that advice and publish one RSA and ECC record for both of my 
mail servers, each. I am using LE certificates with a stable private key that I 
revoke once in a while.


(This is not one of Viktor's recommendations: I publish a '3 1 1' record 
derived from a self-signed certificate in addition, mainly for manually 
interventions in potential LE disaster recovery purposes.)

Regards,
Michael

___
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: spf and Permerror

[Carlos Velasco via Postfix-users]

natan via Postfix-users escribió el 27/06/2024 a las 15:48:

W dniu 27.06.2024 o 15:39, Scott Kitterman via Postfix-users pisze:
Hi Scott
Jun 27 15:39:06 MX policyd-spf[3729]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=200.28.23.150;
helo=200-28-23-150.baf.movistar.cl; envelope-from=c...@bozon.pl;
receiver=

Jun 27 15:39:10 MX policyd-spf[3715]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=158.220.89.240;
helo=server.creatimercado.pl; envelope-from=bou...@creatimercado.pl;
receiver=

Jun 27 15:40:19 MX policyd-spf[3623]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=54.37.233.219;
helo=vps-91050aa8.vps.ovh.net; envelope-from=c...@wowpromo.pl;
receiver=

Jun 27 15:41:19 MX policyd-spf[3772]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=40.107.222.136;
helo=ind01-max-obe.outbound.protection.outlook.com;
envelope-from=c...@b2bexportsllc.com; receiver=

Jun 27 15:41:36 MX policyd-spf[5165]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=209.85.208.47;
helo=mail-ed1-f47.google.com; envelope-from=cc...@lexgedania.pl;
receiver=

Jun 27 15:23:05 MX policyd-spf[51357]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=209.85.221.54;
helo=mail-wr1-f54.google.com; envelope-from=cc...@p1fuels.com;
receiver=

Jun 27 15:33:06 MX policyd-spf[2191]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=209.85.166.74;
helo=mail-io1-f74.google.com; envelope-from=c...@bombilloamarillo.com;
receiver=

Jun 27 15:34:45 MX policyd-spf[2455]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=209.85.167.52;
helo=mail-lf1-f52.google.com; envelope-from=cc...@inis.pl;
receiver=

Jun 27 15:41:36 MX policyd-spf[5165]: prepend Received-SPF: Permerror
(mailfrom) identity=mailfrom; client-ip=209.85.208.47;
helo=mail-ed1-f47.google.com; envelope-from=c...@lexgedania.pl;
receiver=

I change to @ from orginal


bozon.pl - Reason: multiple SPF records. This is not allowed.
;; ANSWER SECTION:
bozon.pl.   3151    IN  TXT "v=spf1 a mx ptr ip4:86.111.240.0/21 
-all"
bozon.pl.   3151    IN  TXT "v=spf1 mx a ~all"

bozon.pl - Reason: multiple SPF records. This is not allowed.
;; ANSWER SECTION:
creatimercado.pl.   28521   IN  TXT "v=spf1 a mx 
include:spf6.aftermarket.hosting -all"
creatimercado.pl.   28521   IN  TXT "v=spf1 a ip4:158.220.89.240 
~all"

wowpromo.pl - Reason: Syntax error, address 2001:41d0:601:1100::35ee is not an 
IPv4 address.
;; ANSWER SECTION:
wowpromo.pl.    3600    IN  TXT "v=spf1 a mx 
ip4:2001:41d0:601:1100::35ee -all"

b2bexportsllc.com - Reason: multiple SPF records. This is not allowed.
;; ANSWER SECTION:
b2bexportsllc.com.  3600    IN  TXT "v=spf1 
include:sender.zohobooks.com"
b2bexportsllc.com.  3600    IN  TXT "v=spf1 
include:dc-aa8e722993._spfm.b2bexportsllc.com ~all include:spf.protection.outlook.com 
-all include:_spf.salesforce.com ~all include:sender.zohobooks.com ~all"

lexgedania.pl - Reason: multiple SPF records. This is not allowed.
;; ANSWER SECTION:
lexgedania.pl.  3600    IN  TXT "v=spf1 include:_spf.google.com 
~all"
lexgedania.pl.  3600    IN  TXT "v=spf1 mx a ptr ~all"

p1fuels.com - Reason: multiple SPF records. This is not allowed.
;; ANSWER SECTION:
p1fuels.com.    300 IN  TXT "v=spf1 include:mailgun.org 
~all"
p1fuels.com.    300 IN  TXT "v=spf1 include:_spf.mlsend.com 
include:_spf.google.com ~all"

bombilloamarillo.com - Reason: not sure about this, but my SPF test bailed out with 
"too many DNS requests". Recursive DNS includes...
;; ANSWER SECTION:
bombilloamarillo.com.   14400   IN  TXT "v=spf1 a mx ptr 
include:bluehost.com ?all"

inis.pl - Reason: not sure about this, but my SPF test bailed out with "too many DNS 
requests". Recursive DNS includes...
;; ANSWER SECTION:
inis.pl.    60  IN  TXT "v=spf1 a mx ip4:89.25.206.16/29 
ip4:147.135.210.113 ip4:213.189.58.137 ip4:185.54.185.228 ip4:185.36.169.40 
ip4:147.135.196.44 ip4:185.54.185.227 include:_spf.mail-source.net 
include:new.ecampaign.pl include:_spf.google.com ~all"

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

[pfx] Re: spf and Permerror

[Matus UHLAR - fantomas via Postfix-users]

On 27.06.24 15:30, natan via Postfix-users wrote:
I have a strange problem with SPF and I honestly don't know what to 
pay attention to


What is a Permerror in SPF
In log i get:

Jun 27 15:09:11 MX policyd-spf[57158]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=84.205.190.72; 
helo=h2.3hosting.pl; envelope-from=gp.szkole...@domain.pl; 
receiver=


This means that IP address 84.205.190.72 tried to send mail from 
gp.szkole...@domain.pl, but the domain.pl admins don't allow their mail 
being send from IP 84.205.190.72


Jun 27 15:09:13 MX policyd-spf[1628]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=40.107.222.124; 
helo=ind01-max-obe.outbound.protection.outlook.com; 
envelope-from=et...@domain2.com; receiver=


If you really want to hide original addresses, you should use reserved 
domain names like example.com, example.net, example.org or .example

- don't make random domain names.


HELO_reject = False
Mail_From_reject = Fail

PermError_reject = False




TempError_Defer = False

skip_addresses = 127.0.0.0/8,:::127.0.0.0/104,::1,
...
Permerror:
 False - Treat PermError the same as no SPF record at all. This is 
consistet with the pre-RFC usage (the pre-RFC name for this error was 
"Unknown").


what could be the reason for this? DNS error/no response? Wrong SPF 
record ? What else?


dns error causes temperror, not permerror.
No answer should mean no SPF Record at all.

Permerror means you got the answer and the sender IP is not allowed for a 
domain.



What you propouse to set in PermError_reject ?


if you want to envorce SPF, set it to true.

Note that there are mails that fail SPF but still pass DMARC test, you may 
want those. rejecting at DMARC level looks safer alternative.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: spf and Permerror

[natan via Postfix-users]

W dniu 27.06.2024 o 15:48, natan via Postfix-users pisze:

W dniu 27.06.2024 o 15:39, Scott Kitterman via Postfix-users pisze:

On June 27, 2024 1:30:37 PM UTC, natan via 
Postfix-users  wrote:

Hi
I have a strange problem with SPF and I honestly don't know what to pay 
attention to

What is a Permerror in SPF
In log i get:

Jun 27 15:09:11 MX policyd-spf[57158]: prepend Received-SPF: Permerror (mailfrom) 
identity=mailfrom; client-ip=84.205.190.72; 
helo=h2.3hosting.pl;envelope-from=gp.szkole...@domain.pl; receiver=

Jun 27 15:09:13 MX policyd-spf[1628]: prepend Received-SPF: Permerror (mailfrom) 
identity=mailfrom; client-ip=40.107.222.124; 
helo=ind01-max-obe.outbound.protection.outlook.com;envelope-from=et...@domain2.com; 
receiver=

postfix-3.4.23
postfix-policyd-spf-python-2.9.2-0

cut /etc/postfix-policyd-spf-python/policyd-spf.conf
...
debugLevel = 1
TestOnly = 1

HELO_reject = False
Mail_From_reject = Fail

PermError_reject = False
TempError_Defer = False

skip_addresses = 127.0.0.0/8,:::127.0.0.0/104,::1,
...
Permerror:
  False - Treat PermError the same as no SPF record at all. This is consistet with the 
pre-RFC usage (the pre-RFC name for this error was "Unknown").

what could be the reason for this? DNS error/no response? Wrong SPF record ? 
What else?

What you propouse to set in PermError_reject ?

If you are not going to tell us the domains involved, there's no way to answer 
your question intelligently.

Scott K

Hi Scott
Jun 27 15:39:06 MX policyd-spf[3729]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=200.28.23.150; 
helo=200-28-23-150.baf.movistar.cl; envelope-from=c...@bozon.pl; 
receiver=


Jun 27 15:39:10 MX policyd-spf[3715]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=158.220.89.240; 
helo=server.creatimercado.pl; envelope-from=bou...@creatimercado.pl; 
receiver=


Jun 27 15:40:19 MX policyd-spf[3623]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=54.37.233.219; 
helo=vps-91050aa8.vps.ovh.net; envelope-from=c...@wowpromo.pl; 
receiver=


Jun 27 15:41:19 MX policyd-spf[3772]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=40.107.222.136; 
helo=ind01-max-obe.outbound.protection.outlook.com; 
envelope-from=c...@b2bexportsllc.com; receiver=


Jun 27 15:41:36 MX policyd-spf[5165]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=209.85.208.47; 
helo=mail-ed1-f47.google.com; envelope-from=cc...@lexgedania.pl; 
receiver=


Jun 27 15:23:05 MX policyd-spf[51357]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=209.85.221.54; 
helo=mail-wr1-f54.google.com; envelope-from=cc...@p1fuels.com; 
receiver=


Jun 27 15:33:06 MX policyd-spf[2191]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=209.85.166.74; 
helo=mail-io1-f74.google.com; envelope-from=c...@bombilloamarillo.com; 
receiver=


Jun 27 15:34:45 MX policyd-spf[2455]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=209.85.167.52; 
helo=mail-lf1-f52.google.com; envelope-from=cc...@inis.pl; 
receiver=


Jun 27 15:41:36 MX policyd-spf[5165]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=209.85.208.47; 
helo=mail-ed1-f47.google.com; envelope-from=c...@lexgedania.pl; 
receiver=


I change to @ from orginal


Or example:

Jun 27 15:49:22 MX policyd-spf[12108]: prepend Received-SPF: Permerror 
(mailfrom) identity=mailfrom; client-ip=52.101.171.91; 
helo=fr6p281cu001.outbound.protection.outlook.com; 
envelope-from=ccc...@schneider-transporte.net; receiver=


host -t txt schneider-transporte.net
schneider-transporte.net descriptive text "v=spf1 
include:spf.protection.outlook.com include:spf-de.emailsignatures365.com 
include:schneider-transporte.net -all"



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




--

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


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