[pfx] Re: vacation segfaults

[John Fawcett via Postfix-users]

On 08/08/2024 23:15, John Fawcett via Postfix-users wrote:


On 08/08/2024 22:36, Wietse Venema via Postfix-users wrote:

Paul Menzel via Postfix-users:

  Stack trace of thread 468215:
  #0  0x00404610 strlcpy (vacation + 0x4610)
  #1  0x00402e0e main (vacation + 0x2e0e)
  #2  0x7f2a6f8a0088 __libc_start_call_main 
(libc.so.6 + 0x2a088)
  #3  0x7f2a6f8a014b 
__libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a14b)

  #4  0x00403525 _start (vacation + 0x3525)
  ELF object binary architecture: AMD x86-64

The root cause could be an unexpected message header.

There are only four strlcpy() calls in the source package for Fedora.
One is to copy the username as looked up from the passwd database,
and the other calls copy information from the From_ line (the first
line of the vacation input) or from the From: header.

The strlcpy() manpage says:

    strlcpy(3bsd) and strlcat(3bsd) are designed to crash if  
the  input

    string is invalid (doesn't contain a terminating null byte).

Do the failing deliveries have the same sender?

Wietse


If the stack trace is to be believed the coredump happens in strlcpy 
called from main. There is only one strlcpy that is called from main 
and that is the one that copies the username as looked up from the 
passwd database. That only happens when there is a -h option on the 
command line, which doesn't seem to be the case. That seems to suggest 
that neither a code error or message input is the cause.


Despite the freebsd manual page the strlcpy code in vacation looks 
safe to me even when copying strings that are not terminated by null.


John


Actually not correct that last statement, I missed this where the code 
keeps  going with while(*s++) until it finds a null termination in the 
input string, though not the cause in this case.


 /* Not enough room in dst, add NUL and traverse rest of src */
  if (n == 0)
    {
  if (siz != 0)
    *d = '\0';  /* NUL-terminate dst */
  while (*s++)
    ;
    }

  return (s - src - 1); /* count does not include NUL */
}

John


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

[pfx] Re: vacation segfaults

[John Fawcett via Postfix-users]

On 08/08/2024 22:36, Wietse Venema via Postfix-users wrote:

Paul Menzel via Postfix-users:

  Stack trace of thread 468215:
  #0  0x00404610 strlcpy (vacation + 0x4610)
  #1  0x00402e0e main (vacation + 0x2e0e)
  #2  0x7f2a6f8a0088 __libc_start_call_main (libc.so.6 + 
0x2a088)
  #3  0x7f2a6f8a014b __libc_start_main@@GLIBC_2.34 
(libc.so.6 + 0x2a14b)
  #4  0x00403525 _start (vacation + 0x3525)
  ELF object binary architecture: AMD x86-64

The root cause could be an unexpected message header.

There are only four strlcpy() calls in the source package for Fedora.
One is to copy the username as looked up from the passwd database,
and the other calls copy information from the From_ line (the first
line of the vacation input) or from the From: header.

The strlcpy() manpage says:

strlcpy(3bsd) and strlcat(3bsd) are designed to crash if  the  input
string is invalid (doesn't contain a terminating null byte).

Do the failing deliveries have the same sender?

Wietse


If the stack trace is to be believed the coredump happens in strlcpy 
called from main. There is only one strlcpy that is called from main and 
that is the one that copies the username as looked up from the passwd 
database. That only happens when there is a -h option on the command 
line, which doesn't seem to be the case. That seems to suggest that 
neither a code error or message input is the cause.


Despite the freebsd manual page the strlcpy code in vacation looks safe 
to me even when copying strings that are not terminated by null.


John

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

[pfx] Re: [OT] Null MX or not?

[John Fawcett via Postfix-users]

On 01/08/2024 09:32, Laura Smith via Postfix-users wrote:




My doubt is that since the outgoing email server identifies itself as
host1.example.com in the EHLO, is there a requirement or even an
expectation that postmas...@example.com will be able to receive email.


I think the reality is that we are in 2024, and the chances of a human reading 
postmaster@ are about the same as a human reading abuse@  i.e. nil.

The whole null-MX thing is very much perceived as the gold standard in security 
conscious environments, e.g. 
https://www.gov.uk/guidance/protect-domains-that-dont-send-email and 
https://en.internet.nl/article/x-xss-protection-removed-and-improvement-for-no-mx-domains/
 etc. etc. etc. etc. etc.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


Thanks Laura, Victor and Wietse for your responses. This info is very 
helpful. Thanks for sharing your knowledge and insights.


John

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

[pfx] Re: [OT] Null MX or not?

[John Fawcett via Postfix-users]

On 31/07/2024 23:34, Wietse Venema via Postfix-users wrote:

I came across something that I have not seen before: a domain (call it
example.com) that has no email addresses. No one sends or receives email
for that domain.

If there is no email from sen...@example.com, the domain should say
so in SPF, DKIM, DMARC, and so on. Cloudflare has a webpage on how
to protect domains that do not send email.

Thanks Wietse I saw that



My doubt is that since the outgoing email server identifies itself as
host1.example.com in the EHLO, is there a requirement or even an
expectation that postmas...@example.com will be able to receive email.

Presumably those other domains list host1.example.com as an authorized
sender. Is that enough? If you're concnerned that the messages would
be flagged as suspicious, then RFC's aren't the whole story.

Wietse


Yes, exactly my doubt, more about pratice than standards I guess.

Thanks

John

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

[pfx] [OT] Null MX or not?

[John Fawcett via Postfix-users]

Hi

this is completely off topic for this list (there is only a marginal 
connection since Postfix is the MTA but it's not a Postfix question), 
but maybe someone has knowledge on this.


I came across something that I have not seen before: a domain (call it 
example.com) that has no email addresses. No one sends or receives email 
for that domain.


The domain has some hosts, e.g. host1.example.com etc which have 
webservers and postfix (null client configuration) used to send outgoing 
email for a domain which is NOT example.com. That other domain can 
receive email via its own incoming MX.


My first thought was to follow RFC7505 and define null mx records for my 
example.com that has no email accounts, so no server will bother to try 
and deliver email to it.


https://www.rfc-editor.org/rfc/rfc7505.html

My doubt is that since the outgoing email server identifies itself as 
host1.example.com in the EHLO, is there a requirement or even an 
expectation that postmas...@example.com will be able to receive email. 
In that case I'd need to define an incoming email server only for that 
purpose, since there are no other email addresses in my example.com


John




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

[pfx] Re: How to bounce e-mail when using catchall

[John Fawcett via Postfix-users]

On 13/07/2024 12:50, Francis Augusto Medeiros-Logeay via Postfix-users 
wrote:


Thanks a lot John and Peter!

In fact this is a family server, so it’s kinda important for us to not 
miss emails. And it happened once that mails were not delivered 
because of typos.


I was a bit worried about nasty consequences when it comes to 
exploitation of using carchall. I just read Peter’s answer about it, 
and he addresses exactly what I was concerned about: that having a 
catchall would signal to the sender that an address exists, thus 
inviting to spam on those addresses.


That said, I haven’t received a single spam on my catchall. I guess 
I’ll keep using it until it proves itself more hassle than not, unless 
there are strong reasons not to keep it.


Thanks a lot!


Hi Francis

while not the "general" practice there is nothing intrinsically bad 
practice with accepting mail for non existent users, so long as you 
don't automate a bounce process after accepting the email. This is one 
of those cases were people say your mileage may vary. Being a family 
server, your volumes of catchall mail are likely to be low anyway. The 
biggest risk is of getting to read something you shouldn't have seen, 
but if all the users know about the way it works that risk has been 
accepted, at least by the recipients.


John


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

[pfx] Re: How to bounce e-mail when using catchall

[John Fawcett via Postfix-users]

On 13/07/2024 06:54, Francis Augusto Medeiros-Logeay via Postfix-users 
wrote:

Hi everyone,

Thanks a lot for your feedback. I learned a lot. So I’ll forget the 
whole thing.


I have a last question, though: are there disadvantages of using a 
catchall compared to not using it, just letting messages bounce when 
the address does not exist instead?


I notice that I don’t get spam with my catchall. It only gets email 
where the sender typed the address wrongly. So I’m not having bad side 
effects of using it. But is it wise to use it, or is it better to let 
servers “know” when an address doesn’t exist as its own mailbox?


Best,
Francis


Hi Francis

I think the answer is it depends.

On servers with a lot of users, I doubt anyone would want to spend time 
reading through a catchall mailbox. My guess is that catchall email 
volumes increase with the number of real users. That mailbox is going to 
be receiving email not just due to typos, but also email to now 
cancelled email addresses etc. There is a privacy question as to who 
would be authorized to read the catchall email box if the server has 
multiple users and/or the domain had email addresses that have been 
cancelled.


The standard solution is to maintain a list of valid users and reject 
recipient addresses not in that list. But your use case may have 
advantages that outweigh any potential disadvantages. Havinga a catchall 
implies that someone is going to be checking it. In that case, with time 
to read the catchall, you may be able to find the time to notify people 
that their email went to the wrong address (for genuine looking emails 
of course).


So ultimately, the suggestion is to weigh up advantages it gives you 
against other constraints like time it takes to manage and privacy 
issues. Personally, I wouldn't spend time on it. I reject invalid 
recipients. If people write to the wrong address they get notified and 
they can correct it if they chose and it is a setup that works without 
manual intervention. I may have lost a few marketing emails like the 
ones that come from "no reply" addresses, but I'm not going to lose 
sleep over it :-)


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

[pfx] Re: Now Dovecot doesn't like me

[John Fawcett via Postfix-users]

On 13/07/2024 02:27, Viktor Dukhovni via Postfix-users wrote:

On Sat, Jul 13, 2024 at 12:01:38AM +0200, John Fawcett via Postfix-users wrote:


I checked https://www.postfix.org/postconf.5.html and I can see:

smtpd_sasl_type (default: cyrus)
     The SASL plug-in type that the Postfix SMTP server should use for
authentication. The available types are listed with the "postconf -a"
command.

     This feature is available in Postfix 2.3 and later.

Indeed: http://www.postfix.org/postconf.5.html#smtpd_sasl_type


While Wietse is not infallable, I'm pretty sure he's close to it in
regards to Postfix :-)

All parameters known to the postconf(1) command are documented in
postconf(5).  The output of:

 $ (
 tmp=$(mktemp -dt config.XX)
 touch "$tmp/main.cf" "$tmp/master.cf"

 # documented parameters, output twice each
 perl -ne 'print "$1\n$1\n" if m{\1}' 
html/postconf.5.html

 # known parameters once each
 postconf -c $tmp -dH

 rm "$tmp/*.cf"; rmdir "$tmp"
   ) | sort | uniq -u

is empty, showing that each parameter known to postconf(1) appears in
the docs.

[ The reason for creating empty main.cf and master.cf files is to avoid
   false positives with _mumble parameters that are synthesised
   on the fly for each master.cf transport even in "postconf -d" output. ]

Thanks Viktor for the confirmation. I know that I'm not impartial as a 
Postfix fan for many years, but in my opinion it's undeniable that the 
Postfix project (Wietse, you and other contributors) have placed an 
importance on documentation that is an example (can't think of a better 
English word, but in Italy we would probably say "lighthouse") for any 
other project.


John

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

[pfx] Re: Now Dovecot doesn't like me

[John Fawcett via Postfix-users]

On 12/07/2024 23:56, John Levine wrote:

It appears that John Fawcett via Postfix-users  said:

I didn't see anywhere what your value of smtpd_sasl_type is (as
applicable to the sasl type used by the smtp server.

Bingo.  Thanks.

In my defence, if you look at https://www.postfix.org/postconf.5.html
which purports to list all of the main.cf parameters, you
will find smtp_sasl_type but not smtpd_sasl_type.  I saw it in
the sasl page but thought it was a typo.

Perhaps someone could add the missing section to the postconf page?

R's,
John


Hi John

glad it's working.

I checked https://www.postfix.org/postconf.5.html and I can see:

smtpd_sasl_type (default: cyrus)
    The SASL plug-in type that the Postfix SMTP server should use for 
authentication. The available types are listed with the "postconf -a" 
command.


    This feature is available in Postfix 2.3 and later.

While Wietse is not infallable, I'm pretty sure he's close to it in 
regards to Postfix :-)


John

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

[pfx] Re: Now Dovecot doesn't like me

[John Fawcett via Postfix-users]

On 12/07/2024 23:13, John R. Levine via Postfix-users wrote:
Hi, now that Viktor spotted the config error and fixed yesterday's 
problem, I'm back with what I hope is another dumb question. Having 
wrestled Cyrus authentication to a draw, now I'm trying Dovecot which 
I would have hoped would be easier.  It's the same Debian box.


First I set up Dovecot and got its password and user databases 
working.  I can log in for IMAP or POP and it works fine.  I have auth 
debug turned on so it has lots to say about the auth request:


Jul 12 17:00:12 debian12 systemd[1]: Reloaded dovecot.service - 
Dovecot IMAP/POP3 email server.
Jul 12 17:00:34 debian12 dovecot[50374]: auth: Debug: Loading modules 
from directory: /usr/lib/dovecot/modules/auth
Jul 12 17:00:34 debian12 dovecot[50374]: auth: Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/lib20_auth_var_expand_crypt.so
Jul 12 17:00:34 debian12 dovecot[50374]: auth: Debug: Read auth token 
secret from /run/dovecot/auth-token-secret.dat
Jul 12 17:00:34 debian12 dovecot[50374]: auth: Debug: passwd-file 
/etc/dovecot/users:Read 3 users in 0 secs
Jul 12 17:00:34 debian12 dovecot[50374]: auth: Debug: auth client 
connected (pid=50378)
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: client in: 
AUTH    1    PLAIN    service=pop3 secured=tls    
session=wc+dLBMdP/6sEJ0B lip=172.16.157.132    
rip=172.16.157.1    lport=995 rport=65087    resp=
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
passwd-file(m...@exotic.qy,172.16.157.1,): 
Performing passdb lookup
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
passwd-file(m...@exotic.qy,172.16.157.1,): lookup: 
user=m...@exotic.qy file=/etc/dovecot/users
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
passwd-file(m...@exotic.qy,172.16.157.1,): Finished 
passdb lookup
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
auth(m...@exotic.qy,172.16.157.1,): Auth request 
finished
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: client passdb 
out: OK    1 user=m...@exotic.qy
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: master in: 
REQUEST    288227329    50378    1 
f96e98986ac3499414a988ea001efb34    session_pid=50382
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
passwd-file(m...@exotic.qy,172.16.157.1,): 
Performing userdb lookup
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
passwd-file(m...@exotic.qy,172.16.157.1,): lookup: 
user=m...@exotic.qy file=/etc/dovecot/users
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: 
passwd-file(m...@exotic.qy,172.16.157.1,): Finished 
userdb lookup
Jul 12 17:00:50 debian12 dovecot[50374]: auth: Debug: master userdb 
out: USER    288227329 m...@exotic.qy uid=1000    gid=1000 
home=/home/mailuser/users/user2    auth_mech=PLAIN
Jul 12 17:00:50 debian12 dovecot[50374]: pop3-login: Login: 
user=, method=PLAIN, rip=172.16.157.1, 
lip=172.16.157.132, mpid=50382, TLS, session=
Jul 12 17:00:51 debian12 dovecot[50374]: 
pop3(m...@exotic.qy)<50382>: Disconnected: Logged 
out top=0/0, retr=0/0, del=0/1, size=275


Then, having done what I think the postfix and dovecot manuals said, I 
try port 465 SMTP AUTH with the same user:


Jul 12 17:01:24 debian12 postfix/submissions/smtpd[50383]: connect 
from unknown[172.16.157.1]
Jul 12 17:01:44 debian12 postfix/submissions/smtpd[50383]: warning: 
SASL authentication failure: Password verification failed
Jul 12 17:01:44 debian12 postfix/submissions/smtpd[50383]: warning: 
unknown[172.16.157.1]: SASL plain authentication failed: 
authentication failure, sasl_username=m...@exotic.qy
Jul 12 17:01:46 debian12 postfix/submissions/smtpd[50383]: disconnect 
from unknown[172.16.157.1] ehlo=1 auth=0/1 quit=1 commands=2/3


It looks like postfix didn't even try to contact the auth server. It 
has the usual socket configured
and lsof says that Dovecot is listening on that socket.  The socket is 
owned by postfix and I am
reasonably sure the directories in the path allow postfix to open it.  
I'm baffled.


Actual config stuff below, since this is my own test system.  TIA.

R's,
John

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 3.6
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 = dovecot
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_path = private/auth
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /e

[pfx] Re: How to bounce e-mail when using catchall

[John Fawcett via Postfix-users]

one point was badly worded below, the following is better:

If you accepted both valid and invalid recipients your reject would be 
for both recipients. (I implied the reject went to the receipient which 
is nonsense).


On 12/07/2024 16:59, John Fawcett via Postfix-users wrote:



On 12/07/2024 15:30, Ralph Seichter via Postfix-users wrote:


I can imagine a custom milter which stores message data, rejects the
original SMTP delivery attempt after the end of the DATA phase, and
later re-injects the captured data in some fashion (not necessarily
using SMTP), but this way madness lies.

"My advice true, forget this!" (Alvina)

-Ralph


Ralph

I agree with the advice but have some doubts about the milter 
solution. Would a milter solution that rejects the message at the end 
of data stage work for the more general case of a multi recipient 
email which contain both valid and invalid recipient addresses? I 
assume that when you get to the end of DATA stage your are either 
rejecting or accepting the message for all recipients that you 
accepted at the RCPT TO stage.


If you accepted both valid and invalid recipients your reject would go 
to both. If you only accept valid recipients and it so happens the 
message was addressed to a single invalid recipient, the smtp session 
would not get to the DATA stage.


John


___
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: How to bounce e-mail when using catchall

[John Fawcett via Postfix-users]

On 12/07/2024 15:30, Ralph Seichter via Postfix-users wrote:


I can imagine a custom milter which stores message data, rejects the
original SMTP delivery attempt after the end of the DATA phase, and
later re-injects the captured data in some fashion (not necessarily
using SMTP), but this way madness lies.

"My advice true, forget this!" (Alvina)

-Ralph


Ralph

I agree with the advice but have some doubts about the milter solution. 
Would a milter solution that rejects the message at the end of data 
stage work for the more general case of a multi recipient email which 
contain both valid and invalid recipient addresses? I assume that when 
you get to the end of DATA stage your are either rejecting or accepting 
the message for all recipients that you accepted at the RCPT TO stage.


If you accepted both valid and invalid recipients your reject would go 
to both. If you only accept valid recipients and it so happens the 
message was addressed to a single invalid recipient, the smtp session 
would not get to the DATA stage.


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

[pfx] Re: How to bounce e-mail when using catchall

[John Fawcett via Postfix-users]

On 12/07/2024 07:17, Francis Augusto Medeiros-Logeay via Postfix-users 
wrote:




On 11 Jul 2024, at 20:22, Bill Cole via Postfix-users 
 wrote:




On 2024-07-11 at 02:42:26 UTC-0400 (Thu, 11 Jul 2024 06:42:26 +)
Francis Augusto Medeiros-Logeay via Postfix-users 
is rumored to have said:

Hi,

I was wondering - is it possible to bounce e-mails for
non-existent addresses when using a catchall?

Define your terms clearly and you willhave a better time finding answers.

What do you mean by "non-existent addresses" in a context where a 
"catchall" exists.




As I said on a previous answer to my question, what I want is this:

I want that mail sent to users who do not have a valid address (like 
when they are not on ldap) to bounce back, like it happens by default, 
but I’d also like these mail to be delivered to an specific mailbox.


As you said, if I use catchall, these addresses would be valid. But 
I’d like the senders to get a bounce email so that they know they sent 
the mail to an address that doesn’t exist or that the destination 
mailbox wasn’t reached.


Is it a bit more clear now?

Best,

Francis




Hi Francis

it may be technically possible some way to deliver and bounce the same 
message, but it is a really bad idea. The best practice is to either 
accept or reject the message in the smtp session. If you reject it you 
won't have the email. If you accept it then you should avoid bouncing it 
later. Otherwise your server could become a source of backscatter and 
end up getting on block lists. Spam routinely uses forged sender 
addresses. If you reject it at the smtp level, then the forged sender is 
not impacted. If you accept and then bounce it, you're bouncing to 
someone who likely did not send the message.


John

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

[pfx] Re: Mysteries of user semi-banning

[John Fawcett via Postfix-users]

On 12/07/2024 00:14, John R. Levine via Postfix-users wrote:

Last month I asked for advice on limiting specific senders
to specific recipients, and Wietse offered this:

/etc/postfix/main.cf:
    smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/restricted_senders

    smtpd_restriction_classes = joe_user_acl
    joe_user_acl =
    check_recipient_access hash:/etc/postfix/joe_user_recipients, 
reject


/etc/postfix/restricted_senders:
    joe_user@some.example  joe_user_acl

/etc/postfix/joe_user_recipients:
    foo@one.example OK
    bar@two.example OK

I tried it on my small test system and it worked fine.  But then we
tried it on the real much more complicated system, and this happened
when sending to a recipient that is not in the allowed list:

 In:  RCPT To:
 Out: 451 4.3.5 Server configuration error

Well, that's strange.  Mail from people not on the restricted list was
fine.  Where should I start looking?  I can't send you the whole main.cf
without getting permission that will take a while, but here's what I
hope might be relevant bits.  For some reason lost in the mists of 
history
they use lmdb: rather than hash: for their hash tables.  Should that 
matter?


R's,
John

smtpd_client_connection_count_limit = 2
smtpd_client_connection_rate_limit = 2
smtpd_client_message_rate_limit = 10
smtpd_client_recipient_rate_limit = 10
smtpd_hard_error_limit = ${stress?1}${stress:4}
smtpd_recipient_limit = 10
smtpd_recipient_overshoot_limit = 10
smtpd_soft_error_limit = 2
smtpd_starttls_timeout = ${stress?10}${stress:15}s
smtpd_timeout = ${stress?10}${stress:15}s
smtpd_client_event_limit_exceptions = (list of domains and IPs not 
related to any restricted ones)


body_checks = regexp:/etc/postfix/body_checks
header_checks = regexp:/etc/postfix/header_checks
smtpd_client_restrictions =

smtpd_sender_login_maps = lmdb:/etc/postfix/accounts
smtpd_data_restrictions =
    reject_unauth_pipelining
    reject_multi_recipient_bounce
    permit
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_invalid_hostname
    reject_non_fqdn_hostname
    permit
smtpd_recipient_restrictions =
  permit_sasl_authenticated
  check_helo_access pcre:/etc/postfix/helo_checks
  check_client_access cidr:/etc/postfix/ipv6_client_check.cidr
  check_sender_access lmdb:/etc/postfix/access
  check_sender_mx_access cidr:/etc/postfix/bogus_mx
  check_recipient_access lmdb:/etc/postfix/recipient_access
  check_recipient_maps
  permit_mynetworks
  reject_sender_login_mismatch
  reject_invalid_hostname
  reject_invalid_helo_hostname
  reject_non_fqdn_hostname
  reject_non_fqdn_helo_hostname
# reject_unknown_helo_hostname
# reject_unknown_client_hostname
  reject_unknown_reverse_client_hostname
  reject_non_fqdn_sender
  reject_unknown_sender_domain
# reject_unlisted_sender
# reject_unverified_sender
  reject_non_fqdn_recipient
  reject_unknown_recipient_domain
  reject_unlisted_recipient
  reject_unverified_recipient
  reject_unauth_destination
  permit

# commented out restriction stuff
#smtpd_sender_restrictions = check_sender_access 
lmdb:/etc/postfix/restricted_senders

#smtpd_restriction_classes = xxx_user_acl
#xxx_user_acl = check_recipient_access 
lmdb:/etc/postfix/allowed_recipients_xxx, reject




# cat restricted_senders
testsen...@abc.com    allowed_recipients_xxx

# cat allowed_recipients_xxx
testa...@mybiz.com    OK


John

I think it's best if you post your configuration (postconf -n) and the 
log messages from this email sending. The logs can contain much better 
info than the reject given in the smtp session.


Postfix supports mixing of different map types so I doubt that lmdb 
usage is part of the issue, unless you didn't run postmap to create 
restricted_senders.lmdb and allowed_recipients.lmdb


It looks as though you have commented out the stuff that Wietse advised 
to add, so that is also unlikely to be part of the issue. Maybe in 
rolling back these changes you inadvertently did something else.


In any case it looks as the commented stuff is not the same as what 
Wietse advised. In the restricted_senders file Wietse said to use 
"joe_user_acl" which in your example would be "xxx_user_acl", whereas 
you have actually used "allowed_recipients_xxx".


John



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

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

[John Fawcett via Postfix-users]

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 <http://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 <http://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 dro

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

[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: managesieve filter not working

[John Fawcett via Postfix-users]

On 04/06/2024 11:18, Celal.Dikici via Postfix-users wrote:

Hello,
For the e-mail infrastructure we use roundcube 1.6.6 postfix 3.7.10, 
dovecot 2.3.19.1 installed on debian 12.05.  We use the larry theme as 
the interface. We use managesieve plugin for filtering. I have 
extracted some configurations below. Although the services are working 
properly, the filtering rules are not working. Although I have 
activated the Sieve logs, no negative logs are being sent. It is as if 
postfix/dovecot is not talking to managesieve. I wonder where I am 
doing wrong?

Thank you for your help.


Hi Celal

this is not a Postfix issue. You will probably find more help about 
sieve on the dovecot mailing list. Postfix itself does not have any 
direct interaction with managesieve or with sieve script interpreter.


I assume that you are using lmtp protocol to deliver email from postfix 
to dovecot. If that's the case then I guess you are missing the 
following dovecot setting for lmtp.


mail_plugins = $mail_plugins sieve

I'd also suggest checking which of your sieve scripts is active and 
therefore supposed to be running during mail delivery. The active one is 
pointed to by a link in the mail directory named dovecot.sieve.


John



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

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

Sorry for following up on my own post, but I want to correct the record. 
Please disregard my previous email. I realize now I made a blunder 
during the analysis, since I was working on two similar questions one 
unrelated to postfix and I mixed up the data sets without realizing it. 
Sorry for the noise.


What I should have posted is that for postfix and xbl for submission 
service, if I take last 30 days of data, xbl blocked 100% of probes 24 
out of 30 days. When probes do get through they tend to do quite a few 
attempts at authenticating, often from the same ip address, so adding 
fail2ban on top has the potential (in my case) to bring the blocking to 
near 100%. The probes that get through generally seem low risk since 
they mainly but not always are for random and inexistent users.


One thing to bear in mind is that the number of probes explicitly 
blocked by xbl as evidenced by the logs may be lower than the number of 
probes being avoided by using it. This would be the case if the probe 
scripts have an adaptive behaviour, increasing the probes where they 
start getting real responses to AUTH and backing off if they get 
disconnected before AUTH.


John

On 29/05/2024 17:46, John Fawcett via Postfix-users wrote:



On 29/05/2024 14:07, Viktor Dukhovni via Postfix-users wrote:

On Wed, May 29, 2024 at 07:26:10AM -0400, John Hill via Postfix-users wrote:


The wrapper-mode TLS "smtps" rejects are naturally after the TLS
handshake.


    465    inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
     ...

     submission inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o 
smtpd_relay_restrictions=permit_sasl_authenticated,permit_mynetworks,reject

All set up this way.
I will let it run overnight and see what hits.

Works like  a charm.

  1   SASL authentication failed ---

Only one.

Perhaps a bit of luck?  For me, the XBL only catches around 10% of the
SASL probes.  May your luck hold up.


The majority of the probes I see that are not stopped by XBL are 
relatively harmless and don't get to try the AUTH command. They mainly 
come from ips that repeat in a short space of time (where potentially 
fail2ban could be used) and


  * fail in the starttls for protocol or cipher issues
  * disconnect without issuing starttls so never get to the AUTH command
  * try issuing AUTH without starttls so get disconnected for too many
invalid commands

The cases I have where AUTH has been tried and failed are relatively 
few. They mainly come from fast varying ips so fail2ban is not that 
useful unless I want to start banning based on a single probe. They 
usually appear to target specific existing users.


John



___
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: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 14:07, Viktor Dukhovni via Postfix-users wrote:

On Wed, May 29, 2024 at 07:26:10AM -0400, John Hill via Postfix-users wrote:


The wrapper-mode TLS "smtps" rejects are naturally after the TLS
handshake.


    465    inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
     ...

     submission inet  n   -   n   -   -   smtpd
     -o smtpd_delay_reject=no
     -o {smtpd_client_restrictions=reject_rbl_client 
zen.spamhaus.org=127.0.0.4}
     -o 
smtpd_relay_restrictions=permit_sasl_authenticated,permit_mynetworks,reject

All set up this way.
I will let it run overnight and see what hits.

Works like  a charm.

  1   SASL authentication failed ---

Only one.

Perhaps a bit of luck?  For me, the XBL only catches around 10% of the
SASL probes.  May your luck hold up.


The majority of the probes I see that are not stopped by XBL are 
relatively harmless and don't get to try the AUTH command. They mainly 
come from ips that repeat in a short space of time (where potentially 
fail2ban could be used) and


 * fail in the starttls for protocol or cipher issues
 * disconnect without issuing starttls so never get to the AUTH command
 * try issuing AUTH without starttls so get disconnected for too many
   invalid commands

The cases I have where AUTH has been tried and failed are relatively 
few. They mainly come from fast varying ips so fail2ban is not that 
useful unless I want to start banning based on a single probe. They 
usually appear to target specific existing users.


John

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

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 02:18, John Hill via Postfix-users wrote:


On 5/28/24 8:10 PM, John Hill via Postfix-users wrote:


On 5/28/24 8:00 PM, Bill Cole via Postfix-users wrote:

On 2024-05-28 at 19:18:10 UTC-0400 (Tue, 28 May 2024 19:18:10 -0400)
John Hill via Postfix-users 
is rumored to have said:
[...

On 5/28/24 7:13 PM, Bill Cole via Postfix-users wrote:

On 2024-05-28 at 19:04:37 UTC-0400 (Tue, 28 May 2024 19:04:37 -0400)
John Hill via Postfix-users 
is rumored to have said:

[...]

Sending of the message failed.
An error occurred while sending mail. The mail server responded:
: Sender address rejected: Email blocked by 
security policy.
Please check the message recipient "postfix-users@postfix.org" 
and try again.


What does the log say about that attempt?

I believe that specific text indicates a problem in 
smtpd_sender_restrictions.


May 28 19:02:04 proteus.noach.com opendmarc[504352]: ignoring 
connection from gibson.noach.com
May 28 19:02:04 proteus.noach.com postfix/submission/smtpd[504893]: 
discarding EHLO keywords: CHUNKING
May 28 19:02:04 proteus.noach.com postfix/submission/smtpd[504893]: 
Anonymous TLS connection established from 
gibson.noach.com[192.168.200.253]: TLSv1.3 with cipher TLS_AES_128_GC
M_SHA256 (128/128 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
May 28 19:02:04 proteus.noach.com postfix/submission/smtpd[504893]: 
discarding EHLO keywords: CHUNKING
May 28 19:02:09 proteus.noach.com postfix/submission/smtpd[504893]: 
NOQUEUE: reject: RCPT from gibson.noach.com[192.168.200.253]: 554 
5.7.1 : Sender address rejec
ted: Email blocked by security policy; from= 
to= proto=ESMTP helo=<[192.168.200.253]>
May 28 19:02:09 proteus.noach.com postfix/submission/smtpd[504893]: 
too many errors after RCPT from gibson.noach.com[192.168.200.253]
May 28 19:02:09 proteus.noach.com postfix/submission/smtpd[504893]: 
disconnect from gibson.noach.com[192.168.200.253] ehlo=2 starttls=1 
auth=1 mail=1 rcpt=0/1 commands=5/6


It's not something in smtpd_sender_restrictions, but this is as the 
log says, a *Sender* stage failure. I don't see an XBL hit (which 
makes sense, given the private client address) or anything 
indicating a failure at the EHLO or client phases. I see from 
earlier in the thread that you have smtpd_sender_login_maps set and 
"Email blocked by security policy" seems like something you might 
get from that lookup failing. The session summary shows that you did 
authenticate but I see no indication of what your SASL login was. I 
suspect that if you perform a query on your database for the sender 
'jh...@noach.com' it will not return whatever login you 
authenticated as.
I also thought for a moment that the problem was due to having 
'permit_my_networks' before 'permit_sasl_authenticated' in 2 
restriction lists and you hence never needing to authenticate, but 
the session summary says otherwise. Note that if all of your 
submission clients use authentication, permit_my_networks is 
unnecessary.


I do not have a solution handy for you, but you have at least gotten 
beyond the XBL issue. It seems possible that you only need to 
harmonize the login used for authentication in Thunderbird with that 
in your sender login map database.


Yes close, I'll figure it out, trial and error!


Thanks

--john

this worked - I think
 -o 
smtpd_recipient_restrictions=permit_sasl_authenticated,reject_rbl_client=zen.spamhaus,org=127.0.0.4,reject



I added and = after reject_rbl_client=



--john

I doubt it. By the time smtpd_recipient_restrictions is evaluated there 
is the possibility that AUTH attempts have already been allowed. Benny's 
suggestion elsewhere in this thread looks correct to me (substituting 
his rbl with zen and return code 127.0.0.4).


John

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

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 01:11, Bill Cole via Postfix-users wrote:

On 2024-05-28 at 18:50:11 UTC-0400 (Wed, 29 May 2024 00:50:11 +0200)
John Fawcett via Postfix-users 
is rumored to have said:

[...]

Hi John

I think you are missing the following in master.cf for the submission 
service


-o smtpd_delay_reject=no

Without that the smtpd_client_restrictions will not be evaluated when 
the client connects and so you will allow the connected client to try 
authentication.


That is not what is happening here. The order of restrictions within 
the same restriction list matters, and Postfix is careful about logic. 
If you put permit_sasl_authenticated ahead of reject_rbl_client, the 
permit must be able to   take effect without evaluating the reject 
condition. That demands allowing as many AUTH commands as your other 
config will allow to fail.



Hi Bill

You're right that the order matters and the reject_rbl_client should be 
the first restriction in smtpd_client_restrictions for the submission 
service. Actually it is probably the only one that is really needed.


I may be wrong but I don't believe that specifying 
permit_sasl_authenticated influences behaviour in allowing AUTH 
attempts. I believe it will just evaluate to permitting the access if at 
the time of the evaluation the user is authenticated.


John

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

[pfx] Re: Masters.cf

[John Fawcett via Postfix-users]

On 29/05/2024 00:27, John Hill via Postfix-users wrote:


On 5/28/24 4:50 PM, John Hill via Postfix-users wrote:


On 5/28/24 4:43 PM, Benny Pedersen via Postfix-users wrote:

John Hill via Postfix-users skrev den 2024-05-28 22:12:

On 5/28/24 3:38 PM, Benny Pedersen via Postfix-users wrote:

John Hill via Postfix-users skrev den 2024-05-28 21:14:


I had dumped the configs but here is what I had.


submission inet n   -   y   -   - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_delay_reject=no
  -o { smtpd_client_restrictions = reject_rbl_client 
auth.spamrats.com=127.0.0.43, permit }
  -o { smtpd_relay_restrictions = permit_mynetworks, 
permit_sasl_authenticated, reject }


https://www.spamrats.com/postfix-configuration.php

works for me :)


Does this look correct. I'm not getting a error, waiting to see if 
it works.!


submission inet  n   -   n   -   - smtpd
  2 -o smtpd_hard_error_limit=1
  3 -o stress=yes
  4 -o syslog_name=postfix/submission
  5 -o smtpd_etrn_restrictions=reject
  6 -o smtpd_sasl_auth_enable=yes
  7 -o smtpd_sasl_type=dovecot
  8 -o smtpd_sasl_path=private/auth
  9 -o smtpd_sasl_security_options=noanonymous
 10 -o smtpd_sasl_tls_security_options=noanonymous
 11 -o 
{smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_rbl_client 
xbl.spamhaus,org=127.0.0.4, reject}
 12 -o 
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

 13 -o smtpd_helo_restrictions=permit_mynetworks,permit
 14 -o smtpd_tls_security_level=encrypt
 15 -o 
smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf

 16 -o milter_macro_daemon_name=ORIGINATING
 17

--john


unneeded complicated

line: 2 5 7 8 9 10 13 15 fits better in main.cf

spamrats allow sending mail when recipient is only local

with your config its rejected


I have been sending mail from local/remote authenticated clients?

--john 
 11 -o 
{smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_rbl_client 
xbl.spamhaus,org=127.0.0.4, reject}


reject_rbl_client doing nothing.

SASL logon fails ips are in manually found in XBL

Postscreen spamhaus blocks work.

postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11] for port 25


--john


Hi John

I think you are missing the following in master.cf for the submission 
service


-o smtpd_delay_reject=no

Without that the smtpd_client_restrictions will not be evaluated when 
the client connects and so you will allow the connected client to try 
authentication.


Personally I use zen.spamhaus.org=127.0.0.4 for submission, but I'm not 
sure that makes any difference respect to xbl.spamhaus.org=127.0.0.4.


Also please check your settings in the config files. In the email above 
I see a comma in xbl.spamhaus,org instead of a dot. If you copied it 
from the config then the config is wrong.


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

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 28/05/2024 11:39, Christophe Kalt via Postfix-users wrote:
On Sun, May 26, 2024 at 5:57 AM John Fawcett via Postfix-users 
 wrote:


For submission I only use xbl (return code 127.0.0.4) excluding
other other data contained in zen like pbl that lists isp dynamic
ip ranges from which you would normally expect to get connections
to submission. For me it's safe to use xbl for submission since I
don't want connections from exploited machines and it cuts out
most of the noise and some of the risk from people hammering smtp
auth. It won't fit everyone's use case though.

For this to be worthwhile, I assume you also set smtpd_delay_reject to 
no ?


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


yes, I set it in master.cf just for submission service.

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

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 27/05/2024 13:31, John Hill via Postfix-users wrote:



On 5/27/24 4:13 AM, Matus UHLAR - fantomas via Postfix-users wrote:

> postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]



John Hill via Postfix-users:

Is this the same thing?


On 25.05.24 15:54, Wietse Venema via Postfix-users wrote:

See https://www.spamhaus.org/faqs/dnsbl-usage/#200 for a table
with the purpose of different lookup results.

To block xbl listed clients with postscreen, one would configure
xbl.spamhaus.org or zen.spamhaus.org=127.0.0.4


While they are the same, I recommend using the latter, so you can 
benefit from caching DNS results in case the same source IP connects 
to smtp and submission/submissions(=smtps) services.


I added the zen,spamhaus,org=127.0.0.[2..11 to my submission settings 
in master.cf. Worked, but it blocked my AT&T mobile block. Go figure!


That's to be expected. The zen.spamhaus.org list also contains isp 
dynamic ip ranges which can be users that need to access submission.


I changed it to 127.0.0.4 to be more specific. It turns out AT&T 
mobile has numbers is in the XBL database. I tried bl.spamcop.net, and 
it does nothing.


If AT&T  is blocked when checking specifically for 127.0.0.4 then the ip 
is in XBL, but that would mean there is a likely to be an exploited 
device on that ip. I would not recommend using spamcop or other general 
purpose spam blocking lists for this purpose. XBL is specific for 
compromised hosts.


Last night I logged  "81 SASL authentication failed." That's about 
average. Seems I have a lot of new friends.


I'm still thankful to learn more about master.cf, I had ignored it for 
the most part.


--john


___
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: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 25/05/2024 20:50, John Hill via Postfix-users wrote:



On 5/25/24 11:22 AM, John Fawcett via Postfix-users wrote:


On 24/05/2024 03:03, John Hill via Postfix-users wrote:
I learn something every time I read this group, when I can keep up 
with the conversation!


I had auth on ports I did not need. I use auth on submission port 
587, for users access.


I do get a boat load of failed login attempts on 587. Funny how a 
China, US, Argentina, you name it, hosts, will try the same failed 
username password at nearly the same time.


Small world.

I use Fail2Ban to block the failed IP. The script writes it into the 
nftables table immediately.


I think this keeps Postfix waiting and times out, not a big deal. Is 
there a cli that my bash script could force disconnect the ip from 
Postfix?


I did search the man page and the docs, sorry if I missed it.

Thanks

--john



Hi John

maybe controversial for use on the submission service, but a while 
back I started using spamhaus xbl (the exploits data only, not the 
PBL or spammer data) as the first check (reject_rbl_client) in 
smtpd_client_restrictions for the submission service (on which I have 
AUTH enabled only after STARTTLS). I saw two results


1. there are few illegitimate smtp auth attempts that aren't blocked 
by XBL and end up trying the credentials


2. even the blocked traffic has fallen off to a small number of tries 
per day (usually < 20).


Point 2 tends to indicate that the hacker scripts only start 
hammering when they find an AUTH command enabled.


Fail2ban can still be used for the ips that get through, since then 
they start hammering, but the cases are so limited I haven't bothered.


John





I use zen.spamhaus.net in postscreen.



postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]

Is this the same thing?
--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 topostfix-users-le...@postfix.org


postscreen is protecting the smtp service (port 25). I also use the zen 
configuration you have above in postscreen, (i.e. including the other 
data not just xbl) since I am more aggressive for smtp.


For submission I only use xbl (return code 127.0.0.4) excluding other 
other data contained in zen like pbl that lists isp dynamic ip ranges 
from which you would normally expect to get connections to submission. 
For me it's safe to use xbl for submission since I don't want 
connections from exploited machines and it cuts out most of the noise 
and some of the risk from people hammering smtp auth. It won't fit 
everyone's use case though.


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

[pfx] Re: How to allow only one specific sender to use smtp ?

[John Fawcett via Postfix-users]

On 25/05/2024 23:58, Mike via Postfix-users wrote:

Hello,

My setup like below:

I have Postfix setup and use dovecot as SASL. Now, all email accounts 
can use the smtp server to send emails. I want to allow only one email 
account to send out emails and rest of others can only use POP3 or IMAP.


How can I make that?

Thanks

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


Hi Mike

as mentioned elsewhere in the thread you could use the sasl backend to 
do this.


For example if using dovecot sasl for the authentication with sql 
backend (and probably with ldap too though I didn't try that), dovecot 
has a %s variable that will be set to the service name (smtp, pop3, imap 
etc) and you can use that variable in the sql query to have different 
responses depending on user and service.


John


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

[pfx] Re: SASL reject force disconnect

[John Fawcett via Postfix-users]

On 24/05/2024 03:03, John Hill via Postfix-users wrote:
I learn something every time I read this group, when I can keep up 
with the conversation!


I had auth on ports I did not need. I use auth on submission port 587, 
for users access.


I do get a boat load of failed login attempts on 587. Funny how a 
China, US, Argentina, you name it, hosts, will try the same failed 
username password at nearly the same time.


Small world.

I use Fail2Ban to block the failed IP. The script writes it into the 
nftables table immediately.


I think this keeps Postfix waiting and times out, not a big deal. Is 
there a cli that my bash script could force disconnect the ip from 
Postfix?


I did search the man page and the docs, sorry if I missed it.

Thanks

--john



Hi John

maybe controversial for use on the submission service, but a while back 
I started using spamhaus xbl (the exploits data only, not the PBL or 
spammer data) as the first check (reject_rbl_client) in 
smtpd_client_restrictions for the submission service (on which I have 
AUTH enabled only after STARTTLS). I saw two results


1. there are few illegitimate smtp auth attempts that aren't blocked by 
XBL and end up trying the credentials


2. even the blocked traffic has fallen off to a small number of tries 
per day (usually < 20).


Point 2 tends to indicate that the hacker scripts only start hammering 
when they find an AUTH command enabled.


Fail2ban can still be used for the ips that get through, since then they 
start hammering, but the cases are so limited I haven't bothered.


John



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

[pfx] Re: Dovecot logging to files causes postfix to break

[John Fawcett via Postfix-users]

On 18/05/2024 18:18, Richard Rosner via Postfix-users wrote:

Am 18.05.24 um 17:55 schrieb Wietse Venema:

Richard Rosner via Postfix-users:

I have a mailing server setup based on Debian Stable that uses
postfix for IMAP and SMTP and dovecot for internel mail handling,

You mean, Postfix for SMTP, Dovecot for IMAP.

Possible.



like filtering, sorting into users inboxes etc. I now wanted to
set dovecot to not write to syslog, but to dedicated files in
/var/log/dovecot. While everything indicates that this happens
successfully, postfix will soon start logging complaints:

 May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9:
 to=, relay=local, delay=3.2, 
delays=1.9/0.29/0/1.1,

 dsn=4.3.0, status=deferred (temporary failure. Command output:
 lda(user): Error: net_connect_unix(/run/dovecot/stats-writer)
 failed: Permission denied Can't open log file
 /var/log/dovecot/error.log: Permission denied )
That is a DOVECOT error message from the DOVECOT local delivery agent 
(lda).


Wietse


Why does it say postfix/local though? So you are sure this error can't 
have been caused by any interaction with postfix?



Richard


Hi Richard

though probably not relevant to your current issue, one thing to watch 
out for with the approach you are using is the value of postfix 
parameter postfix mailbox_size_limit. This value applies to all files 
written by the lda process that postfix spawns, not just the mailbox 
files, so also applies to log file sizes.


John

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

[pfx] Re: client checks with suspect IPs

[John Fawcett via Postfix-users]

On 16/01/2024 20:28, Alex via Postfix-users wrote:

Hi,

I need help with making a decision involved in determining whether to 
add an IP to my client_checks to bypass a blocklist entry on the 
Barracuda blocklist that is impacting one of our users. The problem is 
that this would also bypass the checks for other Zix hosted customers.


Jan 16 12:04:30 xavier postfix-118/postscreen[1006916]: NOQUEUE: 
reject: RCPT from  74.203.184.40]:3602: 550 5.7.1 Service unavailable; 
client [74.203.184.40] blocked using DNS Blocklist (barracuda); 
from=, to=, 
proto=ESMTP, helo=http://zh-gw.zixsmbhosted.com>>


I was also thinking I could add a sender_check for users at 
myclient.com  domain only, but that didn't work. 
The above entry relates to a client reject, but shouldn't a 
sender_check involving myclient.com  work as well?


smtpd_client_restrictions =
        permit_mynetworks,
        check_client_access ${indexed}client_checks,
        check_client_access pcre:$config_directory/client_checks.pcre,
        check_reverse_client_hostname_access 
pcre:$config_directory/reverse_client_hostname_access.pcre,

        check_client_access cidr:$config_directory/client_access_blocklist

/etc/postfix-118/client_checks.pcre:
/74\.203\.184\.40/                      OK

smtpd_sender_restrictions =
        permit_mynetworks,
        check_sender_access ${indexed}sender_checks,
        check_sender_access pcre:$config_directory/sender_checks.pcre,
        reject_unknown_sender_domain

/etc/postfix-118/sender_checks.pcre:
/myclient\.com/             permit

Any ideas greatly appreciated.


Hi Alex

that rejection is happening in postscreen, before handing off to smtpd 
so anything you configure in smtpd is not going to allow this email to 
pass. You'll at least need to allow this ip in the postscreen 
configuration for it to get to smtpd.


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

[pfx] Re: relay_domains override for smtpd

[John Fawcett via Postfix-users]

On 16/01/2024 18:12, Marc Dierksen via Postfix-users wrote:

Salutations,

I am running Postfix 3.5.23 on Debian 11 as an edge mailserver that 
accepts mails on port 25 for a list of domains defined as 
relay_domains in the main.cf.


I am currently trying to setup a second smtpd process on port 587 that 
accepts mails only for local recipients.


I have added the following entry to the master.cf:

587    inet  n   -   y   -   -   smtpd
    -o relay_domains=
    -o content_filter=
    -o 
receive_override_options=no_unknown_recipient_checks,no_address_mappings,no_header_body_checks,no_milters

    -o smtpd_helo_restrictions=
    -o smtpd_client_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_relay_restrictions=
    -o 
smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination

    -o mynetworks=127.0.0.0/8

The idea is that the reject_unauth_destination will reject all mails 
except for local recipients because relay_domains is empty.


Problem is mails for all the domains defined as relay_domains in the 
main.cf are still accepted.


If I set relay_domains to empty in the main.cf it works as expected.

So it seems to me the '-o relay_domains=' parameter for smtpd does not 
work correctly. According to the man page of smtpd however it should 
be supported.


Am I overlooking something?


Hi Marc

I'm probably missing something, but what would be the advantage of 
setting up a separate smtpd processes for this?  Out of curiosity how 
are these emails being sent to port 587?


One suggestion is to customize the syslog name of the new smtpd instance 
in master.cf so as to easily distinguish the logging that comes from the 
two processes.


  -o syslog_name=postfix/submission

Could you show the log entries of what you are seeing when email arrives 
on port 587?


Thanks

John



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

[pfx] Re: recipient_bcc_maps clarification.

[John Fawcett via Postfix-users]

On 08/01/2024 05:54, anant--- via Postfix-users wrote:

Hello,

We have in main.cf always_bcc = zz...@xx.com and our domain is xx.com

For specific 2 recipients of our domain, we don't want always_bcc to 
be implemented.  ie. if a mail is addressed to a...@xx.com  (our domain 
only), mail should not be Bcc to zz...@xx.com. similarly if mail 
recipient is d...@xx.com (our domain only), mail should not be Bcc to 
zz...@xx.com.  For all others always_bcc to continue.


So, in summary, main.cf

always_bcc = zz...@xx.com
recipient_bcc_maps=regexp:/etc/postfix/regexp_recipient_bcc


#regexp_recipient_bcc

#/etc/postfix/regexp_recipient_bcc

a...@xx.com    a...@xx.com
d...@xx.com    d...@xx.com

Whether the above configuration will enable to get desired results? 
ie. always_bcc should not work for a...@xx.com and d...@xx.com and 
instead the mails are delivered to a...@xx.com and d...@xx.com only.



H Anant

I don't think that will work: if you try it I think you will find you 
get two copies of the email to a...@xx.com and d...@xx.com and still get 
all mails copied to zz...@xx.com without achieving the aim because the 
copy will alzo go to zz...@xx.com i.e. these are all cumulative 
configurations.


You will need to eliminate the always_bcc configuration since you don't 
always want all email to be bcced. You should only have the 
recipient_bcc_maps configured.


Since this map is searched according to the search order indicated here 
https://www.postfix.org/postconf.5.html#recipient_bcc_maps you could try 
to map the more specific addresses to /dev/null and have a domain wide 
bcc for the rest.


In order to do it and depending on how your domains are configured you 
might need a local alias in the aliases file to send mail to /dev/null 
file, e.g.


devnull:    /dev/null

Then you can use that as bcc destination for those addressed that should 
skip bcc copies.


#/etc/postfix/regexp_recipient_bcc

a...@xx.com    devnull
d...@xx.com    devnull
@xx.com    zz...@xx.com

Postfix will still generate bcc messages for emails to abc and def but 
they won't actually get sent out.


best regards

John

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

[pfx] Re: Regarding reject_unlisted_sender and preventing sender address spoofing

[John Fawcett via Postfix-users]

On 05/01/2024 19:44, Taco de Wolff via Postfix-users wrote:

Hi,

I'm trying to understand how the reject_unlisted_sender option works 
in the smtpd_sender_restrictions option. This is what I understand it 
to do:


For any received mail (it is an smtpd option after all), either for 
receiving mail from an external server or for sending mail from a 
logged in user with SASL, it checks whether the sender domain 
(envelope FROM) is a valid recipient address (ie. in my case the 
domain exists in the virtual_mailbox_domains) for this server, and if 
it is not it will reject.


When testing however, it was accepting mail from an external server 
(gmail) to be delivered to an existing mailbox, but the sender domain 
was x...@gmail.com which is not a listed sender for my server 
obviously! Why are these mails not rejected? I don't want them to be 
rejected, but it is what I understood reject_unlisted_sender to do.


My goal is to prevent spoofing of the envelope FROM (since we can't 
control the header FROM from Postfix) for outgoing mail, I do this by 
setting smtpd_sender_login_maps and adding 
reject_sender_login_mismatch to the smtpd_sender_restrictions. This 
works perfectly for SASL authenticated users by forcing the envelope 
FROM to be the same as the login username (u...@domain.com), and I 
think the reject_unlisted_sender option would be redundant in this 
case. However, mail delivered locally (sendmail from system or from 
PHP) is not checked by the smtpd options, and I need a way to force 
the envelope sender for certain system users to 
nore...@primary-domain-of-user.com so that a PHP application can't 
spoof the envelope FROM when using sendmail. I use `sendmail -f 
nore...@primary-domain-of-user.com --` as the PHP sendmail_path, but 
I'd like to force this in Postfix for security.


Regarding spoofing of the header FROM, if they use a different domain 
name than their envelope FROM (whether it is a permitted sender for 
the server or not), the destination server will likely reject it due 
to invalid DKIM. This is something I'll take up with the milter 
(rspamd) that does the DKIM signing, to reject any mail that it cannot 
DKIM sign. It will be possible to use a different local part: 
int...@example.com could impersonate himself as ad...@example.com (not 
sure if that is something I want to fix).


Kind regards,
Taco de Wolff

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


Hi Taco

you might find the address class readme useful in this context 
https://www.postfix.org/ADDRESS_CLASS_README.html#classes.


A reject_unlisted_recipient that worked as you are suggesting, that can 
reject x...@gmail.com, would not be useful since your server cannot have 
the list of potentially valid senders for domains that are not managed 
by your server. Such addresses are in the "default domain class" which 
does not have any "valid recipient" table.


The thing to note about reject_unlisted_sender is that it rejects the 
senders that would be rejected as recipients by 
reject_unlisted_recipient. i.e. it rejects senders that would not be 
valid recipients on your server.


So if address aaa@yourdomain does not exist on your server 
reject_unlisted_sender would reject it. If address bbb@yourdomain does 
exist reject_unlisted_sender would not reject it.


So if you are aiming to prevent forgeries ariving via smtp at port 25 
then reject_unlisted_sender will do this for a subset (those that are 
not valid addresses for your server). If you want to prevent all 
forgeries, you'd need to set up a sender access table with e REJECT 
action for your domain(s), and obviously not apply that to submission. 
However that could break some legitimate use cases, such as mail forwarding.


As for adding security to php use of sendmail, sendmail does not enforce 
the kind of controls you want. If you are concerned about forgeries from 
php then it is best to disable the use of sendmail from php or 
substitute the php sendmail setting with something custom that peforms 
the controls you want before invoking sendmail.


If you disable sendmail from php that way people will have to 
authenticate to your submission service from php to send emails.


John








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

[pfx] Re: 25 years today

[John Fawcett via Postfix-users]

On 14/12/2023 14:20, Wietse Venema via Postfix-users wrote:

As a few on this list may recall, it is 25 years ago today that the
"IBM secure mailer" had its public beta release. This was accompanied
by a nice article in the New York Times business section.


Thanks Wietse and to all who have contributed.

Apart from being the only MTA software I'd want to use, this project 
stands out for its exemplary software engineering from design to 
implementation and for the dedication to it's support and evolution.


Happy anniversary Wietse and everyone!

John

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