about double bounce
Hello Let me question about double bounce. I am using postfix 2.10. For double bounce, the document is too few to understand the behavior of double bounce. I confirmed the following documents. There is a point I do not understand, please let me ask a question. Postfix Address Verification Howtohttp:// www.postfix.org/ADDRESS_VERIFICATION_README.html 1.About "By default, Postfix probe messages have a sender address "double-bounce@$myorigin" " What is "probe messages"? I do not know what the survey message in the mail is. 2. About "Postfix always discards mail to the double-bounce address" By default, Postfix recognizes double bounce discard, is it correct? How does "double bounce address" detect "double bounce ",and discard it? I can not find the document explaining the mechanism, so could you tell me? Or is there something helpful?
Re: Click tracker removal ideas?
Greetings, Phil Stracchino! > Quick question I hope: > Does anyone have any suggestions for a tool for filtering out click > trackers from links in email bodies and rewriting the links without the > click tracking? How would you distinguish a click tracking link from password restoration link? -- With best regards, Andrey Repin Friday, February 15, 2019 14:55:51 Sorry for my terrible english...
Re: Logging change with Postfix 3.4.0-RC2
Greetings, Lex Scarisbrick! > The 3.4.0-RC2 version of Postfix appears to have dropped support for > logging via TCP Unix sockets. > As recently as 3.3.0 Postfix used a TCP Unix socket to connect to syslog. No. It used a UNIX domain socket, not TCP. > This is obliquely referenced in the release notes: > [Incompat 20190126] This introduces a new master.cf service 'postlog' > with type 'unix-dgram' that is used by the new postlogd(8) daemon. > Before backing out to an older Postfix version, edit the master.cf > file and remove the postlog entry. > I was able to work around this by logging to stdout and piping to the > logger command, but perhaps it's worth a separate callout that the old > logging behavior is no longer supported. Perhaps there's a way to do this in > 3.4.0-RC2 that I've missed? I don't understand, what you are doing, and why, at all. Care to explain? -- With best regards, Andrey Repin Friday, February 15, 2019 15:01:05 Sorry for my terrible english...
Re: Click tracker removal ideas?
Greetings, Jan P. Kessler! >>> Does anyone have any suggestions for a tool for filtering out click >>> trackers from links in email bodies and rewriting the links without >>> the click tracking? >> Anything that does this will also break DKIM, if the email has it >> (which many do). But perhaps you are confident that your users won't >> be bothered about this. > Isn't DKIM usually checked at MX (or at a downstream content filter)? > Then it would not necessarily bother users: It is checked where it is checked. This includes MUA for those capable of validating it. > Step-1: MX checks DKIM, acts on that information (reject or pass) and > optionally removes DKIM-header > Step-2: MX passes mail to click track remover, after that to user's mailbox > Or did I miss something? Other message signing techniques, as indicated above. -- With best regards, Andrey Repin Friday, February 15, 2019 14:56:57 Sorry for my terrible english...
Re: about double bounce
natsu: > Hello > > Let me question about double bounce. > > I am using postfix 2.10. > > For double bounce, the document is too few to understand the behavior of > double bounce. > I confirmed the following documents. There is a point I do not understand, > please let me ask a question. > > > Postfix Address Verification Howtohttp:// > www.postfix.org/ADDRESS_VERIFICATION_README.html > > 1.About "By default, Postfix probe messages have a sender address > "double-bounce@$myorigin" " > > What is "probe messages"? probe = message that is created for the purpose to verify an email address. > 2. About "Postfix always discards mail to the double-bounce address" > > By default, Postfix recognizes double bounce discard, is it correct? > > How does "double bounce address" detect "double bounce ",and discard it? > I can not find the document explaining the mechanism, so could you tell me? > Or is there something helpful? To recognize an email address, Postfix compares the content of two character strings stored as a sequence of octets. One character string contains "double-bounce" and the other contains informatiom from an email address that resolves to the local domain (matches mydestination or inet_interfaces). "to discard" means "to throw away". Wietse
Re: Logging change with Postfix 3.4.0-RC2
Lex Scarisbrick: > The 3.4.0-RC2 version of Postfix appears to have dropped support for > logging via TCP Unix sockets. As recently as 3.3.0 Postfix used a TCP Unix > socket to connect to syslog. This is obliquely referenced in the release > notes: Postfix calls the syslog(3) system library function, so if anything has changed there, complain to your vendor. Wietse
rewrite sender envelope address based on recipient
Hello, I have been using Postfix for many years - wonderful piece of software. I need to re-write a sender envelope address to "boun...@gmail.com" only if the recipient matches "my...@gmail.com". Can someone point me in the correct direction? thanks itguy -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Click tracker removal ideas?
Wouldn't procmail do something like this? I haven't used procmail for quite some time, but iirc it can handle passing to a filter program, then the filter can hand it to the lmtp (dovecot for instance). Just a thought. I now return to the lurkers lair. --Curtis On February 15, 2019 6:58:00 AM EST, Andrey Repin wrote: >Greetings, Jan P. Kessler! > Does anyone have any suggestions for a tool for filtering out click trackers from links in email bodies and rewriting the links without the click tracking? >>> Anything that does this will also break DKIM, if the email has it >>> (which many do). But perhaps you are confident that your users won't >>> be bothered about this. > >> Isn't DKIM usually checked at MX (or at a downstream content filter)? >> Then it would not necessarily bother users: > >It is checked where it is checked. This includes MUA for those capable >of >validating it. > >> Step-1: MX checks DKIM, acts on that information (reject or pass) and >> optionally removes DKIM-header >> Step-2: MX passes mail to click track remover, after that to user's >mailbox > >> Or did I miss something? > >Other message signing techniques, as indicated above. > > >-- >With best regards, >Andrey Repin >Friday, February 15, 2019 14:56:57 > >Sorry for my terrible english... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: about double bounce
Wietse Thank you for your reply. Because I am not able to understand much about the following because of lack of study, Can you explain it in a bit more detail? Please. > To recognize an email address, Postfix compares the content of two > character strings stored as a sequence of octets. > string contains "double-bounce" and the other contains informatiom > from an email address that resolves to the local domain (matches > mydestination or inet_interfaces). What is "two character strings"? Does Postfix usually store "two character strings"? Addresses are verified by injecting probe messages into the Postfix queue.Is the queue manager "double bounce address" detect "double bounce", and discard it? Is "double-bounce address" pointing to "double-bounce@$myorigin"? I will wait for your reply. Thank you very much. 2019年2月15日(金) 21:08 Wietse Venema : > natsu: > > Hello > > > > Let me question about double bounce. > > > > I am using postfix 2.10. > > > > For double bounce, the document is too few to understand the behavior of > > double bounce. > > I confirmed the following documents. There is a point I do not > understand, > > please let me ask a question. > > > > > > Postfix Address Verification Howtohttp:// > > www.postfix.org/ADDRESS_VERIFICATION_README.html > > > > 1.About "By default, Postfix probe messages have a sender address > > "double-bounce@$myorigin" " > > > > What is "probe messages"? > > probe = message that is created for the purpose to verify an email > address. > > > 2. About "Postfix always discards mail to the double-bounce address" > > > > By default, Postfix recognizes double bounce discard, is it correct? > > > > How does "double bounce address" detect "double bounce ",and discard it? > > I can not find the document explaining the mechanism, so could you tell > me? > > Or is there something helpful? > > To recognize an email address, Postfix compares the content of two > character strings stored as a sequence of octets. One character > string contains "double-bounce" and the other contains informatiom > from an email address that resolves to the local domain (matches > mydestination or inet_interfaces). > > "to discard" means "to throw away". > > Wietse >
Re: Click tracker removal ideas?
On 2/15/19 7:23 AM, Curtis Maurand wrote: > Wouldn't procmail do something like this? I haven't used procmail for > quite some time, but iirc it can handle passing to a filter program, > then the filter can hand it to the lmtp (dovecot for instance). I think filtering it with procmail suffers from the same problems as filtering it during Postfix delivery. Even a browser extension is only going to be able to get the lowest hanging fruit. I remember now that I tried such a browser extension once, calling itself a link de-obfuscator, Clean Links, and it's actually still installed but just seems to miss most of the trackers. I may be able to reconfigure it to catch more of the low-hanging fruit. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Logging change with Postfix 3.4.0-RC2
> On Feb 15, 2019, at 7:02 AM, Andrey Repin wrote: > >> The 3.4.0-RC2 version of Postfix appears to have dropped support for >> logging via TCP Unix sockets. >> As recently as 3.3.0 Postfix used a TCP Unix socket to connect to syslog. > > No. It used a UNIX domain socket, not TCP. The OP meant 'stream'. -- Viktor.
Re: Slowness after upgrading from postfix 2.x to 3.1.8
On Mon, 2019-01-14 at 12:42 +0100, Christopher R. Gabriel wrote: > On Fri, 2019-01-04 at 19:56 +0100, Matus UHLAR - fantomas wrote: > > On 04.01.19 15:23, Christopher R. Gabriel wrote: > > > I have a generator server which injects (via smtp) into postfix, > > > the > > > actual sender, and when burst of delivery happens, the receiving > > > postfix stuck before answering to the generator, which causes the > > > generator queues to fill up. > > > Nov 30 09:11:58 postfix01 postfix-main/smtpd[31800]: abort all > > > milters > > > Nov 30 09:11:58 postfix01 postfix-main/smtpd[31800]: > > > milter8_abort: > > > abort milter inet:127.0.0.1:12301 > > > postfix01 data/spool are on tmpfs. > > > > are you OK with losing mail when something breaks? > > Yes > > > > smtpd_milters = inet:127.0.0.1:12301 > > > > is this milter running properly? > > That's opendkim. No error or strange behaviour reported. After more investigation, the problem is opendkim. No errors logged by it, but when the milter is enabled, during peaks the delay goes from 0.05 up to 25/30. The project seems a bit abandonware (no answers to bugs in years, repository almost stuck), and also recently orphaned by debian maintainer. Does anybody have some hint to check for this, or maybe a more maintained alternative to it? Thank you! Christopher
Re: about double bounce
natsu: > Wietse > > Thank you for your reply. > > Because I am not able to understand much about the following because of > lack of study, > Can you explain it in a bit more detail? Please. > > > To recognize an email address, Postfix compares the content of two > > character strings stored as a sequence of octets. > > string contains "double-bounce" and the other contains informatiom > > from an email address that resolves to the local domain (matches > > mydestination or inet_interfaces). > > What is "two character strings"? Does Postfix usually store "two character > strings"? Sorry, this is the Postfix mailing list. This is not the right forum to explain how computer systems handle strings. Wietse
Re: Slowness after upgrading from postfix 2.x to 3.1.8
Hi Christopher, I'm on the opendkim list also and it does get little attention. Is the "delay" recorded in a typical Postfix log entry ? Stolen from Postfix 2.3.19: Postfix logs additional delay information as "delays=a/b/c/d" where a=time before queue manager, including message transmission; b=time in queue manager; c=connection setup time including DNS, HELO and TLS; d=message transmission time. These seem to be the only settings to bump up logging with opendkim: ## Log activity to the system log. Syslog yes ## Log additional entries indicating successful signing or verification of messages. SyslogSuccess yes ## If logging is enabled, include detailed logging about why or why not a message was ## signed or verified. This causes an increase in the amount of log data generated ## for each message, so set this to No (or comment it out) if it gets too noisy. LogWhy yes If your version supports it you may want to add this to your opendkim config file ? Or check "man opendkim.conf" for more options ? KeepTemporaryFiles (boolean) Instructs the filter to create temporary files containing the header and body canonicalizations of messages that are signed or verified. The location of these files can be set using the TemporaryDirectory parameter. Intended only for debugging verification problems. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Slowness after upgrading from postfix 2.x to 3.1.8
On Fri, 2019-02-15 at 09:35 -0700, angelo wrote: > Hi Christopher, > I'm on the opendkim list also and it does get little attention. Really? :) > Is the "delay" recorded in a typical Postfix log entry ? > Stolen from Postfix 2.3.19: > Postfix logs additional delay information as "delays=a/b/c/d" > where a=time before queue manager, including message transmission; > b=time in queue manager; c=connection setup time including DNS, > HELO and TLS; d=message transmission time. yes, that's from where I get such data from, like delay=31, delays=30/0/0.33/1.1, And it's consistent with the problem reported (if you read the thread backwards) > These seem to be the only settings to bump up logging with opendkim: [..] > If your version supports it you may want to add this to your opendkim > config > file ? > Or check "man opendkim.conf" for more options ? I've already made it extremely verbose, including setting MilterDebug, but it just report the success of the operation, nothing else. > KeepTemporaryFiles (boolean) > Instructs the filter to create temporary files > containing the > header and body canonicalizations of messages that are > signed or verified. > The location of these files can be set using the TemporaryDirectory > parameter. Intended only for debugging verification problems. Signatures are applied correctly, it just take too much time to do it. Regards, Christopher
Re: Slowness after upgrading from postfix 2.x to 3.1.8
Christopher R. Gabriel: > On Fri, 2019-02-15 at 09:35 -0700, angelo wrote: > > Hi Christopher, > > I'm on the opendkim list also and it does get little attention. > > Really? :) > > > Is the "delay" recorded in a typical Postfix log entry ? > > Stolen from Postfix 2.3.19: > > Postfix logs additional delay information as "delays=a/b/c/d" > > where a=time before queue manager, including message transmission; > > b=time in queue manager; c=connection setup time including DNS, > > HELO and TLS; d=message transmission time. > > yes, that's from where I get such data from, like > > delay=31, delays=30/0/0.33/1.1, Can you strace the opendkim process? Is it hanging in DNS lookups? Wietse
Re: Slowness after upgrading from postfix 2.x to 3.1.8
On Friday, February 15, 2019 05:01:45 PM Christopher R. Gabriel wrote: ... > The project seems a bit abandonware (no answers to bugs in years, > repository almost stuck), and also recently orphaned by debian > maintainer. ... FYI, that was me. I orphaned it because I'm not using it anymore. As far as I know, it still works fine. I did get tired of the slow pace of development (I was interested in implementing Ed25519 DKIM signatures), so I wrote dkimpy- milter and use it now instead. It is not nearly as featurefull as OpenDKIM, but it does the things I need. Scott K
Re: Slowness after upgrading from postfix 2.x to 3.1.8
On Fri, 15 Feb 2019, 18:28 Wietse Venema Christopher R. Gabriel: > > On Fri, 2019-02-15 at 09:35 -0700, angelo wrote: > > > Hi Christopher, > > > I'm on the opendkim list also and it does get little attention. > > > > Really? :) > > > > > Is the "delay" recorded in a typical Postfix log entry ? > > > Stolen from Postfix 2.3.19: > > > Postfix logs additional delay information as "delays=a/b/c/d" > > > where a=time before queue manager, including message transmission; > > > b=time in queue manager; c=connection setup time including DNS, > > > HELO and TLS; d=message transmission time. > > > > yes, that's from where I get such data from, like > > > > delay=31, delays=30/0/0.33/1.1, > > Can you strace the opendkim process? Is it hanging in DNS lookups? > > Wietse > It's in signing mode only, and we I try to strace it (with follow option for thread) it crashes. Christopher >
3.3.0 -> 3.3.2 and sasl error
Hi, I've attempted upgrade of my postfix docker container from alpine 3.8 (which has postfix 3.3.0) to alpine 3.9 (postfix 3.3.2). Perfectly working config which just worked with 3.3.0 now causing SASL auth error: warning: SASL authentication failure: No worthy mechs found Here is verbose logging from container: smtp_1 | 2019-02-16T04:33:01.621125+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-host.domain.com smtp_1 | 2019-02-16T04:33:01.621166+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-PIPELINING smtp_1 | 2019-02-16T04:33:01.621170+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-SIZE 104857600 smtp_1 | 2019-02-16T04:33:01.621174+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-VRFY smtp_1 | 2019-02-16T04:33:01.621177+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-ETRN smtp_1 | 2019-02-16T04:33:01.621182+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-AUTH PLAIN LOGIN smtp_1 | 2019-02-16T04:33:01.621186+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-AUTH=PLAIN LOGIN smtp_1 | 2019-02-16T04:33:01.621191+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-ENHANCEDSTATUSCODES smtp_1 | 2019-02-16T04:33:01.621196+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-8BITMIME smtp_1 | 2019-02-16T04:33:01.621199+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250-DSN smtp_1 | 2019-02-16T04:33:01.621203+00:00 xxx postfix/smtp[106]: < host.domain.com[IP.ADDRESS]:587: 250 SMTPUTF8 smtp_1 | 2019-02-16T04:33:01.621215+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: plain ~? auth smtp_1 | 2019-02-16T04:33:01.621314+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: plain ~? login smtp_1 | 2019-02-16T04:33:01.621326+00:00 xxx postfix/smtp[106]: match_list_match: PLAIN: no match smtp_1 | 2019-02-16T04:33:01.621330+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: login ~? auth smtp_1 | 2019-02-16T04:33:01.621334+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: login ~? login smtp_1 | 2019-02-16T04:33:01.621406+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: plain ~? auth smtp_1 | 2019-02-16T04:33:01.621415+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: plain ~? login smtp_1 | 2019-02-16T04:33:01.621418+00:00 xxx postfix/smtp[106]: match_list_match: PLAIN: no match smtp_1 | 2019-02-16T04:33:01.621422+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: login ~? auth smtp_1 | 2019-02-16T04:33:01.621425+00:00 xxx postfix/smtp[106]: match_string: smtp_sasl_mechanism_filter: login ~? login smtp_1 | 2019-02-16T04:33:01.621432+00:00 xxx postfix/smtp[106]: server features: 0x20902f size 104857600 smtp_1 | 2019-02-16T04:33:01.621451+00:00 xxx postfix/smtp[106]: Using ESMTP PIPELINING, TCP send buffer size is 87040, PIPELINING buffer size is 4096 smtp_1 | 2019-02-16T04:33:01.621522+00:00 xxx postfix/smtp[106]: maps_find: smtp_sasl_password_maps: host.domain.com: not found smtp_1 | 2019-02-16T04:33:01.621540+00:00 xxx postfix/smtp[106]: maps_find: smtp_sasl_password_maps: hash:/etc/postfix/sasl_passwd(0,lock|fold_fix|utf8_request): [host.domain.com]:587 = username:password smtp_1 | 2019-02-16T04:33:01.621552+00:00 xxx postfix/smtp[106]: smtp_sasl_passwd_lookup: host `host.domain.com' user `username' pass `password' smtp_1 | 2019-02-16T04:33:01.621599+00:00 xxx postfix/smtp[106]: starting new SASL client smtp_1 | 2019-02-16T04:33:01.621650+00:00 xxx postfix/smtp[106]: smtp_sasl_authenticate: host.domain.com[IP.ADDRESS]:587: SASL mechanisms LOGIN smtp_1 | 2019-02-16T04:33:01.621668+00:00 xxx postfix/smtp[106]: warning: SASL authentication failure: No worthy mechs found Could you please point me into correct directions on what's causing SASL auth failure? Thanks.
Re: 3.3.0 -> 3.3.2 and sasl error
* sashk : > Hi, > > I've attempted upgrade of my postfix docker container from alpine 3.8 (which > has postfix 3.3.0) to alpine 3.9 (postfix 3.3.2). Perfectly working config > which just worked with 3.3.0 now causing SASL auth error: warning: SASL > authentication failure: No worthy mechs found > > Here is verbose logging from container: > > smtp_1 | 2019-02-16T04:33:01.621125+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-host.domain.com > smtp_1 | 2019-02-16T04:33:01.621166+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-PIPELINING > smtp_1 | 2019-02-16T04:33:01.621170+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-SIZE 104857600 > smtp_1 | 2019-02-16T04:33:01.621174+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-VRFY > smtp_1 | 2019-02-16T04:33:01.621177+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-ETRN > smtp_1 | 2019-02-16T04:33:01.621182+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-AUTH PLAIN LOGIN > smtp_1 | 2019-02-16T04:33:01.621186+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-AUTH=PLAIN LOGIN The other side offers PLAIN LOGIN, but your smtp client doesn't like that because those are mechanisms which send identification data in clear (read: unencrypted). That's because you have this (default) in place: smtp_sasl_security_options = noplaintext, noanonymous Either you make sure your smtp client uses TLS, while it attempts to authenticate or you lower the security policy and configure your smtp client to permit PLAIN and/or LOGIN like this: smtp_sasl_security_options = noanonymous This removes the noplaintext restriction and only forbids usage of anonymous mechanisms. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: rewrite sender envelope address based on recipient
It's my first time posting to a mailing list, my apologies.
I am using Postifix v3.1.0-3ubuntu0.3 on Ubuntu Xenial. The server is an
email relay server for our production network with each server being able to
connect if a) it's ip address is whitelisted or b) it uses smtp-auth when
connecting to port 587.
We have an invoicing system on a different host that clients use to send out
invoices and test invoices. The invoicing system generates and sends the
email to the server in question, which then relays the email to the client's
mail exchanger.
We are in a situation whereby we would like to keep the client's email
address in the from header but change the envelope sender address of all
emails to be our support email (in order to receive all bounces).
I am aware that using "sender_canonical_maps" with
"canonical_classes=envelope_sender" will work. However, this will change all
envelope sender address. We would only like to change the envelope sender if
the recipient matches a specific address. Is this possible?
The closest that I have come to making this work is to create a new smtp
service in master.cf and use a header check to match the recipient and
FILTER it to a new smtp service in master.cf. The problem here is that
canonical maps won't work because it is carried out by Postfix's cleanup
service, which does its work before inserting the email into the queue.
Based on HEADER_CHECKS(5), FILTER is the same as content_filter which is
executed after the email has been inserted into the queue.
Please find my main.cf below:
mail_owner = postfix
setgid_group = postdrop
smtpd_banner = $myhostname - SMTP
mydomain = domain.com
myhostname = hostname.$mydomain
message_size_limit = 2500
default_destination_recipient_limit = 15
smtpd_recipient_limit = 50
inet_interfaces = all
inet_protocols = ipv4
mydestination = $myhostname
mynetworks = 127.0.0.1
myorigin = $myhostname
local_transport = local
local_recipient_maps = $alias_maps unix:passwd.byname
alias_maps = hash:/etc/aliases
alias_database = $alias_maps
relay_domains = hash:/etc/postfix/maps/relay_domains
transport_maps = pcre:/etc/postfix/maps/transport
biff = no
disable_mime_input_processing = no
strict_rfc821_envelopes = no
show_user_unknown_table_name = no
queue_run_delay = 300s
bounce_queue_lifetime = 1d
maximal_queue_lifetime = 2d
minimal_backoff_time = 120s
maximal_backoff_time = 1800s
header_checks = regexp:/etc/postfix/maps/header_checks
local_header_rewrite_clients = static:all
postscreen_greet_action = enforce
postscreen_access_list = permit_mynetworks,
hash:/etc/postfix/maps/postscreen_checks
smtpd_tls_exclude_ciphers = RC4, aNULL
smtp_tls_exclude_ciphers = RC4, aNULL
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_dns_support_level = enabled
disable_vrfy_command = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
check_helo_access hash:/etc/postfix/maps/helo_checks,
reject_non_fqdn_helo_hostname,
reject_invalid_hostname,
reject_unauth_pipelining,
permit_sasl_authenticated,
permit_mynetworks,
permit
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/maps/sender_checks,
permit_sasl_authenticated,
permit_mynetworks,
permit
smtpd_client_restrictions = hash:/etc/postfix/maps/client_checks
smtpd_relay_restrictions =
check_client_access hash:/etc/postfix/maps/client_checks,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_invalid_helo_hostname,
reject_invalid_hostname,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_recipient_domain
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access hash:/etc/postfix/maps/client_checks,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:10023
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
soft_bounce = no
dont_remove = 1
smtpd_delay_reject = yes
notify_classes =
helpful_warnings = yes
delay_notice_recipient =
error_notice_recipient =
bounce_notice_recipient =
2bounce_notice_recipient =
delay_warning_time = 24h
default_destination_concurrency_limit = 1
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = cyrus
smtp_use_tls = yes
smtpd_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_sc
Re: 3.3.0 -> 3.3.2 and sasl error
Greetings, Patrick Ben Koetter! >> Hi, >> >> I've attempted upgrade of my postfix docker container from alpine 3.8 >> (which has postfix 3.3.0) to alpine 3.9 (postfix 3.3.2). Perfectly working >> config which just worked with 3.3.0 now causing SASL auth error: warning: >> SASL authentication failure: No worthy mechs found >> >> Here is verbose logging from container: >> >> smtp_1 | 2019-02-16T04:33:01.621125+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-host.domain.com >> smtp_1 | 2019-02-16T04:33:01.621166+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-PIPELINING >> smtp_1 | 2019-02-16T04:33:01.621170+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-SIZE 104857600 >> smtp_1 | 2019-02-16T04:33:01.621174+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-VRFY >> smtp_1 | 2019-02-16T04:33:01.621177+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-ETRN >> smtp_1 | 2019-02-16T04:33:01.621182+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-AUTH PLAIN LOGIN >> smtp_1 | 2019-02-16T04:33:01.621186+00:00 xxx postfix/smtp[106]: < >> host.domain.com[IP.ADDRESS]:587: 250-AUTH=PLAIN LOGIN > The other side offers PLAIN LOGIN, but your smtp client doesn't like that > because those are mechanisms which send identification data in clear (read: > unencrypted). That's because you have this (default) in place: > smtp_sasl_security_options = noplaintext, noanonymous > Either you make sure your smtp client uses TLS, while it attempts to > authenticate or you lower the security policy and configure your smtp client > to permit PLAIN and/or LOGIN like this: > smtp_sasl_security_options = noanonymous > This removes the noplaintext restriction and only forbids usage of anonymous > mechanisms. You really should not lower security of your system without a very good reason. The option you are looking for is... smtp_tls_security_level = may ...but... The bad news is that remote does not offer STARTTLS. -- With best regards, Andrey Repin Saturday, February 16, 2019 9:43:14 Sorry for my terrible english...
