Re: Message sent by SMTP get lost whereas those via pickup(sendmail) are OK
On Sun, May 16, 2021 at 10:14:45PM +0200, Jaroslaw Rafa wrote: > Dnia 16.05.2021 o godz. 13:58:22 Bob Proulx pisze: > > Chris Green wrote: > > > I am trying to debug it by connecting directly to port 25 on localhost > > > using telnet and composing mail that way. > > > > I highly recommend "swaks" the Swiss Army Knife SMTP, the all-purpose > > SMTP transaction tester utility program for generating test emails > > using SMTP transactions. For example: > > Ubuntu desktop should have Thunderbird preinstalled. Why not just try to > send mail using a regular mail client? Most mail clients will use sendmail rather than SMTP on port 25 (or another port) won't they? As I said my postfix works fine for sending E-Mails from my MUA (mutt) which uses sendmail. I must say that swaks looks handy though and it's available from the Ubuntu repositories so it's very easy for me to install and use. -- Chris Green
Re: Message sent by SMTP get lost whereas those via pickup(sendmail) are OK
On Mon, May 17, 2021 at 09:03:25AM +0200, Jeroen Geilman wrote: >It was not rejected by mail.gandi.net. > >If it was rejected by something beyond that, [1]ch...@zmbc.eu would get >a bounce notification (DSN). > >Postfix is not involved in any way. > OK, thanks. -- Chris Green
Re: Message sent by SMTP get lost whereas those via pickup(sendmail) are OK
Dnia 17.05.2021 o godz. 08:52:33 Chris Green pisze: > > > > Ubuntu desktop should have Thunderbird preinstalled. Why not just try to > > send mail using a regular mail client? > > Most mail clients will use sendmail rather than SMTP on port 25 (or > another port) won't they? As I said my postfix works fine for sending > E-Mails from my MUA (mutt) which uses sendmail. Most *desktop* mail clients can use either submission or SMTP on port 25 (you can configure that), as they are intended to be used on machines where no MTA is installed at all, so no sendmail. Thunderbird, as far as I remember (I haven't used it for a few years, I use Evolution as my desktop client now) can be configured to use locally installed sendmail, but this is a special case. Submission or SMTP is still the default method of sending mail it uses. -- 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."
Re: Message sent by SMTP get lost whereas those via pickup(sendmail) are OK
On 17/05/21 9:12 pm, Jaroslaw Rafa wrote: Dnia 17.05.2021 o godz. 08:52:33 Chris Green pisze: Most mail clients will use sendmail rather than SMTP on port 25 (or another port) won't they? As I said my postfix works fine for sending E-Mails from my MUA (mutt) which uses sendmail. Most *desktop* mail clients can use either submission or SMTP on port 25 (you can configure that), as they are intended to be used on machines where no MTA is installed at all, so no sendmail. This needs to be said because it has been glossed over or missed in this thread. Email clients use submission or submissions over port 587 or 465 respectively. It is an unfortunately common practice to misuse port 25 for submission and it only (sometimes) works because many mail servers are configured to allow this incorrect usage due to its commonality. Port 25 is actually for MX to MX communication and really isn't supposed to be used for submission at all. So please remember: Port 465 = submissions = best Port 587 with mandatory starttls = submission = acceptable Port 587 with optional starttls or plain text only = not recommended Port 25 = smtp = not appropriate for submission. Peter
Re: Message sent by SMTP get lost whereas those via pickup(sendmail) are OK
Dnia 17.05.2021 o godz. 21:55:22 Peter pisze: > > Port 465 = submissions = best > Port 587 with mandatory starttls = submission = acceptable I would disagree that port 465 with TLS-wrapper around SMTP is better than port 587 with STARTTLS. It's only your personal opinion. Port 587 with mandatory STARTTLS is in no way less secure than TLS-wrapped port 465. In fact, port 587 with STARTTLS is more standards-compliant than port 465, because the latter has never been published as official standard. My personal opinion would be completely contrary to yours: use port 587 with (mandatory) TLS whenever possible, only if the server does not offer it, but offers TLS-wrapped port 465, fall back to that instead. But all this discussion has nothing to the original question, as the OP explictly wanted to test sending mail via port 25. -- 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."
Re: Message sent by SMTP get lost whereas those via pickup(sendmail) are OK
On 17/05/21 10:37 pm, Jaroslaw Rafa wrote: I would disagree that port 465 with TLS-wrapper around SMTP is better than port 587 with STARTTLS. It's only your personal opinion. Port 587 with mandatory STARTTLS is in no way less secure than TLS-wrapped port 465. I used to make that argument (see below). In fact, port 587 with STARTTLS is more standards-compliant than port 465, because the latter has never been published as official standard. This is incorrect: https://datatracker.ietf.org/doc/html/rfc8314 My personal opinion would be completely contrary to yours: use port 587 with (mandatory) TLS whenever possible, only if the server does not offer it, but offers TLS-wrapped port 465, fall back to that instead. A couple of years ago I would have said the same, but times have changed and standards have been updated, and with good reason. Even with mandatory encryption enabled on the server side there is still an attack channel open for clients (and they do exist) that offer opportunistic encryption from the client side. A MITM can block the encrypted connection on the port, offer a plain text only connection and then in turn connect to the server with STARTTLS. This allows the MITM to bypass the encryption mandated by the server and still eavesdrop and even actively alter the content of the communication. This is why RFC8314 now recommends that plain text protocols such as submission on 587 be discouraged in favor of implicit TLS connections such as submissions (port 465). Hence my recommendation that submissions is preferred and submission with mandatory starttls is acceptable. But all this discussion has nothing to the original question, as the OP explictly wanted to test sending mail via port 25. Which in and of itself is wrong. Port 25 is not for the submission of mail since April 2006 when RFC 4409 officially split the functions of submission and relaying to separate ports. Peter
Unwanted disclosure of email addresses
Hi, have you ever got an email containing lots of email addresses including your own in the TO or CC field or somewhere else in the mail body? I think, this happens for different reasons: - people sending emails to many recipients don't know or don't care how to do that properly - people dont' know abount BCC - people forgot to use BCC instead of CC - email/calendar programs like outlook/exchange send invitations without the senders interaction including all invitees in the to/cc as well as in the text/calendar mime-body part containung an icalendar event - people replying to all header recipients after receiving such mails I don't like that and have thought about a solution: - use a postfix serve as an outgoing smarthost - use header_checks to identify mails with to much CC/TO recipients - use body_checks to identify mails containing a text/calendar mime part - use a special transport to process these mails - use _destination_recipient_limit 1 in the postfix config to split the mail and process the mail one by one recipient - the deamon accepting the redirected mails will: - unpack the mail recursively - shorten CC and TO headers to the (single) recipient plus some maybe white listed recipients plus 'undisclosed recipients' - eventually remove tons of other useless mail headers (configurable) - unpack the ical part and remove all invitees but the current recipient - create a new ical part with only one single invitee - compose a new mail and send it to the current recipient feeding it back to postfix - I'm not sure, if it's necessary to split the mail, because the daemon could also unpack once and create many new mails out of it. I have to understand better how postfix's internal mail flow works exactly. Is this really a good idea? Is there anybody out there interested in it and want's to give it a try? I have sort of an alpha-version in perl running and would share it on gitlab after some additional work on it if somebody is looking for a solution like this and want's to discuss about or comment on it. \Magnus -- Dr. Magnus Harlander Mail: har...@harlan.de Web: www.harlan.de Stiftung: www.harlander-stiftung.de Ceterum censeo bitcoin esse delendam!
Re: Unwanted disclosure of email addresses
On 5/17/21 8:00 AM, Magnus Harlander wrote: > Hi, > > have you ever got an email containing lots of email addresses > including your > own in the TO or CC field or somewhere else in the mail body? > > I think, this happens for different reasons: > > - people sending emails to many recipients don't know or don't care > how to do that > properly > - people dont' know abount BCC > - people forgot to use BCC instead of CC > - email/calendar programs like outlook/exchange send invitations without > the senders interaction including all invitees in the to/cc as well > as in the text/calendar mime-body part containung an icalendar event > - people replying to all header recipients after receiving such mails > > I don't like that and have thought about a solution: > ... > Is this really a good idea? > > \Magnus I think the biggest problem with your solution is that sometimes it really isn't a 'problem' and is the right answer. It might be desirable to let the group be able to 'Reply-All' to the message to discuss some things related to it. This means breaking it at the server level has REALLY broken it. You don't want to prohibit at the server level things that you might want to allow in some cases. This might make a great feature at the MDA level, where it pops up a warning that the visable recipient list is long, and ask if you want to make it a BCC: list instead, but enforcing this breaks some workflows. Unless you really want to prohibit that activity, you can't do it at the server level. -- Richard Damon
Re: Unwanted disclosure of email addresses
On 2021-05-17 at 08:00:30 UTC-0400 (Mon, 17 May 2021 14:00:30 +0200) Magnus Harlander is rumored to have said: Is this really a good idea? Not really. For mail which does not originate within the scope of your authority to set policy, you would be interfering with the intent of a sender who is not normally subject to your rules and with what they are trying to communicate to their correspondents. This will inevitably create conflict, because in many cases it is desirable to have all recipients aware of who else is receiving a message (particularly a meeting invitation) and to enable the ad hoc mailing list-like functionality that comes from everyone in a conversation using "Reply All" consciously. It also will break any existing DKIM signatures and in the case of calendar items where you are modifying the body of the message it will also break OpenPGP and S/MIME signatures, which are typically applied by the MUA. Of course, ultimately the traditional maxim applies: "Your server, your rules." No one is going to stop you from doing this with a server you control. Since you are comfortable using Perl, you might want to implement this on top of the existing MIMEDefang milter, which is designed for doing radical message surgery of this sort and is configured by implementing Perl subroutines for each of the milter phases. That would spare you from using header_checks and body_checks (which are very limited.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Unwanted disclosure of email addresses
Am 17.05.21 um 14:17 schrieb Richard Damon: > On 5/17/21 8:00 AM, Magnus Harlander wrote: >> Hi, >> >> have you ever got an email containing lots of email addresses >> including your >> own in the TO or CC field or somewhere else in the mail body? >> >> I think, this happens for different reasons: >> >> - people sending emails to many recipients don't know or don't care >> how to do that >> properly >> - people dont' know abount BCC >> - people forgot to use BCC instead of CC >> - email/calendar programs like outlook/exchange send invitations without >> the senders interaction including all invitees in the to/cc as well >> as in the text/calendar mime-body part containung an icalendar event >> - people replying to all header recipients after receiving such mails >> >> I don't like that and have thought about a solution: >> ... >> Is this really a good idea? >> >> \Magnus > I think the biggest problem with your solution is that sometimes it > really isn't a 'problem' and is the right answer. It might be desirable > to let the group be able to 'Reply-All' to the message to discuss some > things related to it. > > This means breaking it at the server level has REALLY broken it. You > don't want to prohibit at the server level things that you might want to > allow in some cases. This might make a great feature at the MDA level, > where it pops up a warning that the visable recipient list is long, and > ask if you want to make it a BCC: list instead, but enforcing this > breaks some workflows. > > Unless you really want to prohibit that activity, you can't do it at the > server level. > I see your point. A few ideas on that: - MDA/MUA would definitely be the better place to do that. There are just so many of them - and we should tell microsoft... - general scrubbing of to/cc could be switched off by config, so it happens only if there is an ical attachment found. This makes sence because in this case you have no chance as a user to avoid the disclosure - we could have an opt-in or opt-out header field or a subject keyword like NOFILTER. I know, this is probably only a solution for nerds - there could be a whitelist of senders - btw. the number of addresses allowed in cc and to is also a config option. \Magnus -- Dr. Magnus Harlander Mail: har...@harlan.de Web: www.harlan.de Stiftung: www.harlander-stiftung.de Ceterum censeo bitcoin esse delendam! OpenPGP_signature Description: OpenPGP digital signature
Re: SASL and PAM
Ivan Avery Frey: > SASL when authenticating via PAM requires a service name. Is the > service name "stmp" hardcoded or is it configurable? That would be SASL configuration. not Postfix configuration. Wietse
Re: SASL and PAM
On 2021-05-17 at 09:32:41 UTC-0400 (Mon, 17 May 2021 09:32:41 -0400 (EDT)) Wietse Venema is rumored to have said: > Ivan Avery Frey: >> SASL when authenticating via PAM requires a service name. Is the >> service name "stmp" hardcoded or is it configurable? > > That would be SASL configuration. not Postfix configuration. Is that not what smtpd_sasl_service configures? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: incoming email SSL errors for only some domains.
On 29/4/21 10:44, P V Anthony wrote:
On 27/4/2021 2:11 pm, Viktor Dukhovni wrote:
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keywords
smtpd-ehlo-discard.cidr:
# NetName: MERCK1
# NetHandle: NET-155-91-0-0-1
155.91.0.0/16 starttls
main.cf:
cidr = cidr:${config_directory}/
smtpd_discard_ehlo_keyword_address_maps =
${cidr}smtpd-ehlo-discard.cidr
Sorry for the late reply.
Thank you very much for the instructions with examples. I do appreciate
it very much.
I have done the setting in postfix. Will report back on the result.
I am happy to say the above configuration is working well.
Just to confirm what the above configuration is doing, am I correct to
say that, for any connections coming from 155.91.0.0/16, the starttls is
not allowed.
P.V.Anthony
Re: SASL and PAM
Bill Cole: > On 2021-05-17 at 09:32:41 UTC-0400 (Mon, 17 May 2021 09:32:41 -0400 (EDT)) > Wietse Venema > is rumored to have said: > > > Ivan Avery Frey: > >> SASL when authenticating via PAM requires a service name. Is the > >> service name "stmp" hardcoded or is it configurable? > > > > That would be SASL configuration. not Postfix configuration. > > Is that not what smtpd_sasl_service configures? That's the pathname of SASL CONFIGURATION Wietse
Re: Posfix, SASL and PAM
On Mon., May 17, 2021, 09:33 Wietse Venema, wrote: > Ivan Avery Frey: > > SASL when authenticating via PAM requires a service name. Is the > > service name "stmp" hardcoded or is it configurable? > > That would be SASL configuration. not Postfix configuration. I'm sorry I didn't make my question clear. When Postfix initializes the SASL library, it uses the service name "smtp"? I tried looking for it in the the source (xsasl_cyrus_server.c), but I couldn't find it. > >
Re: Posfix, SASL and PAM
Ivan Avery Frey: > On Mon., May 17, 2021, 09:33 Wietse Venema, wrote: > > > Ivan Avery Frey: > > > SASL when authenticating via PAM requires a service name. Is the > > > service name "stmp" hardcoded or is it configurable? > > > > That would be SASL configuration. not Postfix configuration. > > > I'm sorry I didn't make my question clear. > > When Postfix initializes the SASL library, it uses the service name "smtp"? > I tried looking for it in the the source (xsasl_cyrus_server.c), but I > couldn't find it. Like this: smtpd_sasl_path (default: smtpd) Implementation-specific information that the Postfix SMTP server passes through to the SASL plug-in implementation that is selected with smtpd_sasl_type. Typically this specifies the name of a configuration file or rendezvous point. smtp_sasl_path (default: empty) Implementation-specific information that the Postfix SMTP client passes through to the SASL plug-in implementation that is selected with smtp_sasl_type. Typically this specifies the name of a configuration file or rendezvous point. Wietse
Re: SASL and PAM
On Mon, May 17, 2021 at 10:07:40AM -0400, Wietse Venema wrote: > Bill Cole: > > On 2021-05-17 at 09:32:41 UTC-0400 (Mon, 17 May 2021 09:32:41 -0400 (EDT)) > > Wietse Venema > > is rumored to have said: > > > > > Ivan Avery Frey: > > >> SASL when authenticating via PAM requires a service name. Is the > > >> service name "stmp" hardcoded or is it configurable? > > > > > > That would be SASL configuration. not Postfix configuration. > > > > Is that not what smtpd_sasl_service configures? > > That's the pathname of SASL CONFIGURATION >From the Postfix history file: 20131224 Feature: smtpd_sasl_service (until now, this was hard-coded internally as "smtp"). On request by Michal (sksoft.cz). Files: global/mail_params.h, proto/postconf.proto, mantools/postlink, smtpd/smtpd.c, smtpd/smtpd_sasl_glue.c. >From the postconf(5) manpage: smtpd_sasl_service (default: smtp) The service name that is passed to the SASL plug−in that is selected with smtpd_sasl_type and smtpd_sasl_path. This feature is available in Postfix 2.11 and later. Prior versions behave as if "smtp" is specified. -- Viktor.
Submission Only, Not Listening on 25.
I am setting up a postfix instance as submission only to compliment dovecot in imap mode. Is there a way to turn off listening on port 25 and only have submission listen on 587? I already know how to bind the submission service to 587 in the master.cf I assume listening on 25 is controlled by inet_interfaces however i don't see anything in docs about specifying "nothing", its either all or a specific IP. Is my only choice to allow postfix to bind to 25 and just firewall it off from the public? If possible id rather disable listening on 25 since its not being used.
Re: Submission Only, Not Listening on 25.
post...@ptld.com: > I am setting up a postfix instance as submission only to compliment > dovecot in imap mode. > Is there a way to turn off listening on port 25 and only have submission > listen on 587? Comment out the service in master.cf that listens on port 25. Command: postconf -# -M smtp/inet Result: # smtp inet n ... ... ... ... smtpd Wietse > I already know how to bind the submission service to 587 in the > master.cf > > I assume listening on 25 is controlled by inet_interfaces however i > don't see anything in docs about specifying "nothing", its either all or > a specific IP. > > Is my only choice to allow postfix to bind to 25 and just firewall it > off from the public? If possible id rather disable listening on 25 since > its not being used. >
Re: Submission Only, Not Listening on 25.
> > > I am setting up a postfix instance as submission only to compliment > dovecot in imap mode. > Is there a way to turn off listening on port 25 and only have submission > listen on 587? > I already know how to bind the submission service to 587 in the > master.cf Any service could be commented out in master.cf > > I assume listening on 25 is controlled by inet_interfaces however i > don't see anything in docs about specifying "nothing", its either all or > a specific IP. > In most cases it is safe to bind it to the "loopback-only" interface Is my only choice to allow postfix to bind to 25 and just firewall it off from the public? You can comment it in master.cf but even if you couldn't, you can always bind it to the localhost only either by preprending smtp service with "127.0.0.1:" in master.conf or by using inet_interfaces="loopback-only" Latter approach is recommended. >
Bind Submission IPv4 & IPv6 in Master.cf
New problem, i can not specify two IP's in the master.cf for submission to bind to. This works: 127.0.0.1:submission inet n - n - - smtpd This works: [::1]:submission inet n - n - - smtpd This does not work: 127.0.0.1,[::1]:submission inet n - n - - smtpd 127.0.0.1 [::1]:submission inet n - n - - smtpd Keeps telling me [space] or [,] is invalid character. How can you bind submission to both IPv4 and IPv6?
Re: Bind Submission IPv4 & IPv6 in Master.cf
On 5/17/2021 5:20 PM, post...@ptld.com wrote: New problem, i can not specify two IP's in the master.cf for submission to bind to. This works: 127.0.0.1:submission inet n - n - - smtpd This works: [::1]:submission inet n - n - - smtpd This does not work: 127.0.0.1,[::1]:submission inet n - n - - smtpd 127.0.0.1 [::1]:submission inet n - n - - smtpd Keeps telling me [space] or [,] is invalid character. How can you bind submission to both IPv4 and IPv6? Use multiple submission entries. Repeat as often as needed to listen on the required IPs. 127.0.0.1:submission inet n - n - - smtpd [::1]:submission inet n - n - - smtpd -- Noel Jones
Cannot connect to email server with client; postfix logs errors
I am setting up a new email server, and I am unable to connect to it with
Icedove, and postfix logs errors when I attempt to do so. I am using
postfix + dovecot + opendkim + spamassassin.
Systemd log:
May 17 15:28:22 gentooserver systemd[1]: Starting Postfix Mail Transport
Agent...
May 17 15:28:22 gentooserver postfix[119364]: Postfix is running with
backwards-compatible default settings
May 17 15:28:22 gentooserver postfix[119364]: See
http://www.postfix.org/COMPATIBILITY_README.html for details
May 17 15:28:22 gentooserver postfix[119364]: To disable backwards
compatibility use "postconf compatibility_level=2" and "postfix reload"
May 17 15:28:23 gentooserver postfix/master[119438]: daemon started --
version 3.5.8, configuration /etc/postfix
May 17 15:28:23 gentooserver systemd[1]: Started Postfix Mail Transport
Agent.
May 17 15:29:50 gentooserver postfix/smtpd[119496]: connect from
unknown[10.0.0.103]
May 17 15:29:50 gentooserver postfix/submission/smtpd[119495]: connect from
unknown[10.0.0.103]
May 17 15:29:50 gentooserver postfix/smtpd[119496]: fatal: host/service
localhost/12301 not found: No such file or directory
May 17 15:29:50 gentooserver postfix/submission/smtpd[119495]: fatal:
host/service localhost/12301 not found: No such file or directory
May 17 15:29:50 gentooserver postfix/smtpd[119499]: connect from
unknown[10.0.0.103]
May 17 15:29:50 gentooserver postfix/submission/smtpd[119500]: connect from
unknown[10.0.0.103]
May 17 15:29:50 gentooserver postfix/smtpd[119499]: fatal: host/service
localhost/12301 not found: No such file or directory
May 17 15:29:50 gentooserver postfix/submission/smtpd[119500]: fatal:
host/service localhost/12301 not found: No such file or directory
May 17 15:29:51 gentooserver postfix/master[119438]: warning: process
/usr/libexec/postfix/smtpd pid 119495 exit status 1
May 17 15:29:51 gentooserver postfix/master[119438]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
May 17 15:29:51 gentooserver postfix/master[119438]: warning: process
/usr/libexec/postfix/smtpd pid 119496 exit status 1
May 17 15:29:51 gentooserver postfix/master[119438]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
May 17 15:29:51 gentooserver postfix/master[119438]: warning: process
/usr/libexec/postfix/smtpd pid 119499 exit status 1
May 17 15:29:51 gentooserver postfix/master[119438]: warning: process
/usr/libexec/postfix/smtpd pid 119500 exit status 1
postconf -n:
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
home_mailbox = Mail/Inbox/
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/lib/dovecot/deliver
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
meta_directory = /etc/postfix
milter_default_action = accept
milter_protocol = 6
myhostname = mail.gentooserver.dehnel.info
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:12301
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix/${mail_version}
smtp_tls_CAfile = /etc/ssl/apache2/cert.pem
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_security_level = may
smtpd_milters = inet:localhost:12301
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/apache2/pfSense.fullchain
smtpd_tls_exclude_ciphers = aNULL, LOW, EXP, MEDIUM, ADH, AECDH, MD5, DSS,
ECDSA, CAMELLIA128, 3DES, CAMELLIA256, RSA+AES, eNULL
smtpd_tls_key_file = /etc/ssl/apache2/pfSense.key
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_security_level = may
tls_preempt_cipherlist = yes
unknown_local_recipient_reject_code = 550
postconf -Mf:
pickup unix n - n 60 1 pickup
cleanupunix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewriteunix - - 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
Re: Submission Only, Not Listening on 25.
On 2021-05-17 23:39, post...@ptld.com wrote: I am setting up a postfix instance as submission only to compliment dovecot in imap mode. +1 Is there a way to turn off listening on port 25 and only have submission listen on 587? put # in front of smtp line in master.cf should be it I already know how to bind the submission service to 587 in the master.cf same here if you dont need this put # infront of that line in master.cf verify by issue "postconf -Mf" if looks good test after restart of postfix, netstat -natpu I assume listening on 25 is controlled by inet_interfaces however i don't see anything in docs about specifying "nothing", its either all or a specific IP. you could do a loop-backonly maybe ? Is my only choice to allow postfix to bind to 25 and just firewall it off from the public? If possible id rather disable listening on 25 since its not being used. see above :)
Re: Submission Only, Not Listening on 25.
On Mon, May 17, 2021 at 05:57:35PM -0400, Wietse Venema wrote: > Comment out the service in master.cf that listens on port 25. > > Command: postconf -# -M smtp/inet > > Result: # smtp inet n ... ... ... ... smtpd A fancier, but more easily programmatically reversed method is: main.cf: master_service_disable = smtp/inet Note that this would have match the master.cf entry name *exactly*, it would not disable "127.0.0.1 inet ... smtpd" or similar. -- Viktor.
Re: Bind Submission IPv4 & IPv6 in Master.cf
On 2021-05-18 00:29, Noel Jones wrote: 127.0.0.1:submission inet n - n - - smtpd [::1]:submission inet n - n - - smtpd localhost:submission inet n - n - - smtpd imho postfix will accept this aswell, not tested
dkim=pass but unprotected
I noticed in the headers it shows: dkim=pass (2048-bit key; unprotected) What does the unprotected part refer to? Anything to worry about? Something i need to setup or configure? I googled but didn't find anything, just people talking about why their dkim didn't pass. I notice emails from gmail and yahoo say unprotected which makes me think its not important.
Re: Cannot connect to email server with client; postfix logs errors
On 2021-05-17 at 19:02:10 UTC-0400 (Mon, 17 May 2021 18:02:10 -0500) Nathan Dehnel is rumored to have said: I am setting up a new email server, and I am unable to connect to it with Icedove, and postfix logs errors when I attempt to do so. I am using postfix + dovecot + opendkim + spamassassin. Systemd log: [...] May 17 15:29:50 gentooserver postfix/smtpd[119496]: connect from unknown[10.0.0.103] May 17 15:29:50 gentooserver postfix/submission/smtpd[119495]: connect from unknown[10.0.0.103] May 17 15:29:50 gentooserver postfix/smtpd[119496]: fatal: host/service localhost/12301 not found: No such file or directory May 17 15:29:50 gentooserver postfix/submission/smtpd[119495]: fatal: host/service localhost/12301 not found: No such file or directory May 17 15:29:50 gentooserver postfix/smtpd[119499]: connect from unknown[10.0.0.103] May 17 15:29:50 gentooserver postfix/submission/smtpd[119500]: connect from unknown[10.0.0.103] May 17 15:29:50 gentooserver postfix/smtpd[119499]: fatal: host/service localhost/12301 not found: No such file or directory [...] postconf -n: [...] smtpd_milters = inet:localhost:12301 Whatever milter you are trying to use on port 12301 (possibly OpenDKIM?) is not running or something in your system config (e.g. iptables firewall) is blocking connections to it. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: dkim=pass but unprotected
It's not dnssec signed. -Dan Mahoney > On May 17, 2021, at 6:14 PM, post...@ptld.com wrote: > > I noticed in the headers it shows: > > dkim=pass (2048-bit key; unprotected) > > What does the unprotected part refer to? > Anything to worry about? Something i need to setup or configure? > I googled but didn't find anything, just people talking about why their dkim > didn't pass. > I notice emails from gmail and yahoo say unprotected which makes me think its > not important.
Mail sent thru submission to user on same server.
If i send mail to submission:587 addressed to another user on the same server, postfix instead of sending the mail to the mx records for that domain, and connecting to postfix on smtp:25 it bypasses all of that and delivers directly into that users inbox. This avoids all of my filtering, smtpd_helo_restrictions, smtpd_recipient_restrictions, ban list, etc. I am hoping for an answer that works in both of these situations. I have two setups, one where everything is self contained on one server with dovecot and postfix. On my second setup i have postfix smtp:25 on one server, and dovecot imap:143 with postfix submission:587 together on another server. I want when someone sends an email from their client to the submission server, the submission server would connect to the smtp:25 server to deliver the mail. But the submission:587 server directly delivered to the user's folder and bypassed the smtp:25 server. How can i avoid this behavior and make postfix deliver the mail to "the front door" smtp:25 even if its a user on the same system?
Re: Mail sent thru submission to user on same server.
On Mon, May 17, 2021 at 11:02:35PM -0400, post...@ptld.com wrote: > If I send mail to submission:587 addressed to another user on the same > server, postfix instead of sending the mail to the mx records for that > domain, and connecting to postfix on smtp:25 it bypasses all of that and > delivers directly into that users inbox. This avoids all of my > filtering, smtpd_helo_restrictions, smtpd_recipient_restrictions, ban > list, etc. If you really MUST avoid direct delivery, you'll need a multi-instance Postfix deployment: http://www.postfix.org/MULTI_INSTANCE_README.html It is not clear why direct delivery from authorised submission users is not OK, but that's your concern I guess. -- Viktor.
