Re: encoding issue with header_checks Windows-1252
So you are saying that the client probably decoded the subject. Thank you Wietse! What might be the best way, to capture all kind of encodings for a specific string in subject? We let our users choose mail routing path, if string is part of subject. Works with all clients, just not with some kind of Outlooks, entering postfix via office 365. Am Samstag, 20. Juli 2019 schrieb Wietse Venema : > Stefan Bauer: >> I dont get it. Testing the above correctly shows >> >> Subject: >> =?Windows-1252?Q?[Cleartext]_Webinar_=84Noch_keine_55_und_ab_in_die_GKV=93?= >> FILTER cleartext: >> >> But the e-mail itself was not passed to the FILTER cleartext. > > Consider the possibiliy that the message subject is different > from what you think it is. > > Hint: Postfix does not decode header or body content. > > Wietse >
Re: encoding issue with header_checks Windows-1252
I dont get it. Testing the above correctly shows Subject: =?Windows-1252?Q?[Cleartext]_Webinar_=84Noch_keine_55_und_ab_in_die_GKV=93?= FILTER cleartext: But the e-mail itself was not passed to the FILTER cleartext. Above subject was extracted from mail client. I believe, there is something going wrong with encoding. Am Do., 18. Juli 2019 um 16:27 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > header_checks = regexp:/etc/postfix/headerstring > > /^Subject: .*\[cleartext\].*/ FILTER cleartext: > > > > And now, there is the following mail-Subject, that did not trigger the > > above FILTER and i dont see why: > > > > Subject: > > > =?Windows-1252?Q?[Cleartext]_Webinar_=84Noch_keine_55_und_ab_in_die_GKV=93?= > > > > Postfix does not decode headers. > > To test: > > echo "Subject: =?Windows-1252?Q?[Cleartext..." |postmap -q - > regexp:/etc/postfix/headerstring > > Wietse >
Re: encoding issue with header_checks Windows-1252
only this single filter is present - no other filters. Unfortunately thats not enough to trigger the filter. Am Do., 18. Juli 2019 um 14:00 Uhr schrieb pasvon : > What does the complete file /etc/postfix/headerstring look like? > Does another line match a filter action and override the desired result? > Have you defined any other header_checks (body for example)? > > That should be enough, too: > /^Subject: .*\[cleartext\]/ FILTER cleartext: > > > > -- > Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html >
Re: encoding issue with header_checks Windows-1252
man 5 header_checks By default, regexp <http://www.postfix.org/regexp_table.5.html>: and pcre <http://www.postfix.org/pcre_table.5.html>: patterns are case *insensitive*. Am Do., 18. Juli 2019 um 13:40 Uhr schrieb Matus UHLAR - fantomas < uh...@fantomas.sk>: > On 18.07.19 13:35, Stefan Bauer wrote: > >header_checks = regexp:/etc/postfix/headerstring > >/^Subject: .*\[cleartext\].*/ FILTER cleartext: > > > >And now, there is the following mail-Subject, that did not trigger the > >above FILTER and i dont see why: > > > >Subject: > > >=?Windows-1252?Q?[Cleartext]_Webinar_=84Noch_keine_55_und_ab_in_die_GKV=93?= > > > "cleartext" vs. "Cleartext" looks like case sensitivity problem. > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > I intend to live forever - so far so good. >
encoding issue with header_checks Windows-1252
Hi, header_checks = regexp:/etc/postfix/headerstring /^Subject: .*\[cleartext\].*/ FILTER cleartext: And now, there is the following mail-Subject, that did not trigger the above FILTER and i dont see why: Subject: =?Windows-1252?Q?[Cleartext]_Webinar_=84Noch_keine_55_und_ab_in_die_GKV=93?= Any ideas? Stefan
Re: best practice lookup table perormance - non hashed file
Thank you for your answer, but this brings in another piece of software. Want to keep it simple. Am Di., 25. Juni 2019 um 13:34 Uhr schrieb Matus UHLAR - fantomas < uh...@fantomas.sk>: > On 24.06.19 21:42, Stefan Bauer wrote: > >we're publishing lookup tables through our control git repo but hashing > all > >tables before commiting them to git is cumbersome. What do you recommend? > > > >several postfix servers are getting same lookup table from central > >repository. > > > >we're using it this ways: > > > >smtpd_sender_restrictions = check_sender_access > >hash:/etc/postfix/allowed_senders > > > >mail-addy or domain OK > >... > > > >with 600 entries so far. > > > >I'm aware of http://www.postfix.org/DATABASE_README.html#types > > > >but none of them look simple. we like it plain and simple. No db or ldap > or > >another instance, that could go wild. > > > >Whate do you recommend? > > you can try rbldnsd and reject_rhsbl_client. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > 2B|!2B, that's a question! >
best practice lookup table perormance - non hashed file
Hi, we're publishing lookup tables through our control git repo but hashing all tables before commiting them to git is cumbersome. What do you recommend? several postfix servers are getting same lookup table from central repository. we're using it this ways: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/allowed_senders mail-addy or domain OK ... with 600 entries so far. I'm aware of http://www.postfix.org/DATABASE_README.html#types but none of them look simple. we like it plain and simple. No db or ldap or another instance, that could go wild. Whate do you recommend? Thank you. Stefan
Re: Stats recommendations?
we're pulling all kind of logs and graph them in fancy ways with zabbix. zabbix has a small client with tiny footprint and can do encrypted transfer of logs/data to server. Am Mo., 17. Juni 2019 um 22:20 Uhr schrieb PGNet Dev : > I'm aware of the list of stats tools > >http://www.postfix.org/addon.html > > Looking for experience/recommendations from users here. > > grep's served me well enough for just a few servers. > > As I switch to all/only Postfix at multiple locations, something easily > automated/deployed is of interest. > DIY is doable; I'd prefer a product/project that's still actively > maintained. > > I'm looking for as lightweight as possible. > > I'm OK with just scheduled text/emailed reports; usual prefer them to > visual displays, whether static or dynamic/realtime, anyway. > > > What are folks here using & happy with? >
Re: authenticate o365 users with postfix without smtp auth
As microsoft ofers DKIM-singing for outgoing mails at no extra cost, i will validate this information as 3rd authentication token. Looks much clearer and several addons for postfix exist to do so. Am Mo., 17. Juni 2019 um 21:31 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > > The latter is simply conservative design. There is no need to forward > this information, and a receiving system might object to receiving > XOORG from a Postfix machine that isn't authorized to send it. > > Wietse >
Re: authenticate o365 users with postfix without smtp auth
Emmanuel, thank you. That was of great help to see, that others have same isses with o365. Do you have any more infos how you do the experimental certificate matching part with postifx? thank you in advance Stefan Am Mo., 17. Juni 2019 um 12:05 Uhr schrieb Emmanuel Fusté < emmanuel.fu...@external.thalesgroup.com>: > Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit : > > On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: > > > >> Some of our users use o365 but would like to use our service for > outgoing > >> mails. We are offering smtp sending services. Integrating our service > in > >> o365 is tricky, as one can only specify a smarthost but microsoft does > not > >> offer any kind of authentication for smarthosts. > > Are these individual users or cloud-hosted domains? Who's authorized > > to ask Microsoft to route their outbound traffic through your relay? > > Can you distinguish one such Office365 sender from another? ... > > > > What's the point (if I may ask) of having their mail sent through > > your relay? I assume that Microsoft could quite easily send their > > outbound traffic directly to its destination. > > > Cloud-hosted domains is "hosting" service. You have the control on the > outbound routing. > There is many reason why you want your outbound traffic not directly > delivered to its destination. > Some want to provide "value added services". In my case is is because > the o365 users are only a fraction of my users (hybrid cloud mode) and > that inboud/ouboud internet mails policy/routing/delivery is under the > control of another infrastructure. > > Microsoft is always presenting a client certificate. That the only way > to authenticate O365. (the experimental certificate matching will help you) > For the next part, the complete missing of outbound SMTP AUTH (under the > control of Microsoft or the client organization) is the difficult/crazy > part. > > The easy/lame way is to match the "under Microsoft control" > X-MS-Exchange-CrossTenant-id header and the SMTP From domains to > filter/differentiate o365 customers. > > The "proper" Microsoft way is to use their proprietary XOORG SMTP > extension used in their hybrid cloud scenario. > => after having authenticated o365 with the presented client > certificate, if you announce the XOORG extension in the EHLO, o365 will > provide you the remote o365 organization (in the "MS Exchange" sense) as > part of the MAIL FROM verb. > MAIL FROM: OORG=my-organization.com > > I have implemented the client part in postfix to not have to deploy 40 > Microsoft Exchange Edge servers in a multi-tenant hybrid cloud scenario > and use only my existing postfix infrastructure between o365 and all my > Exchange platforms. It is the easy part. A few simple lines of code. I > don't know what Wietse and Viktor will think about it, so I did not > submit it yet... Will do. Would be great if it could be integrated in > one form or another. > > The hard part is the server part. Will do it some day to simplify our > tenants authentication, but I think that it will be more controversial > and will understand if Wietse and Viktor do not want such thing in Postfix. > As it is a SMTP extension, I did not find a generic mechanism in which > XOORG would fit and which could be added to postfix. > For my use case, as I've done for another reason for the certificate > case, I will add the possibility to silently map an XOORG value to a > SASL id to do proper source domain ownership filtering > (reject_xx_login_mismatch mumbles). > > Emmanuel. >
Re: authenticate o365 users with postfix without smtp auth
I'm glad you're asking. These are cloud-hosted domains at microsofts exchange online (o365) infrastructure. Each user can set outgoing routing to smarthosts(called connectors) in exchanges admin-center. But - as said, no smtp-authentication is offered. We're providing sending-capabilities paired with archive & delivery statistics. So our customers can just sign-up for our services, set there relayhost (in postfix terms) and we take care of the rest. Our non-postfix-users, that are having o365 as mail infrastructure, can set as well a smarthost BUT without any smtp-authentication capability. Thats our problem. We would like to accept our customer mails, coming from the MS world, but need some good/strong way, to authenticate them appropriately. so far, only sender-domain/address and MS own-published ip-ranges are factors, we have available. Am So., 16. Juni 2019 um 22:37 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote: > > > Some of our users use o365 but would like to use our service for outgoing > > mails. We are offering smtp sending services. Integrating our service > in > > o365 is tricky, as one can only specify a smarthost but microsoft does > not > > offer any kind of authentication for smarthosts. > > Are these individual users or cloud-hosted domains? Who's authorized > to ask Microsoft to route their outbound traffic through your relay? > Can you distinguish one such Office365 sender from another? ... > > What's the point (if I may ask) of having their mail sent through > your relay? I assume that Microsoft could quite easily send their > outbound traffic directly to its destination. > > -- > Viktor. >
Re: authenticate o365 users with postfix without smtp auth
Bill, yes thats the question. i would consider the two factors as reliable. MS is signing mails. i just like clear user authentication instead of rely on volatile ips/blocks, microsoft publishes/changes. what i need to check is also, whether MS allows spoofing of sender address. i need to make sure, no user can use our service, just by sending through any ms account with a correctly guessed allowed sender address. far away from perfect. Am Sonntag, 16. Juni 2019 schrieb Bill Cole < postfixlists-070...@billmail.scconsult.com>: > So if you know that the SMTP client matches SPF (or a statically-set address set) for the sender domain AND the sender address is one you intend to service, how reliably is the mail authenticated by those 2 elements together? > > Is the mail DKIM signed? > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) >
Re: authenticate o365 users with postfix without smtp auth
MS is publishing source ips/ranges. sasl_exeptions_networks seems an option but i still dont like the lack of authentication. Am Sonntag, 16. Juni 2019 schrieb Wietse Venema : > Stefan Bauer: >> its like the first: >> >> end-user client -> microsoft server -> postfix server -> remote recipient > > How would Postfix know that the server is Microsoft Office 365? > From the reverse DNS? > > Wietse >
Re: authenticate o365 users with postfix without smtp auth
its like the first: end-user client -> microsoft server -> postfix server -> remote recipient Am Sonntag, 16. Juni 2019 schrieb Wietse Venema : > Stefan Bauer: >> our users send/receive via o365. the last mile o365->recipient should go >> through our service like o365->postfix->recipient > > Dumb question: is the mail flow like this: > > end-user client -> microsoft server -> postfix server -> remote recipient > > Or is it something else? > - Local recipient? > - End-user office 365 client -> postfix server? > > Please be explicit about the client and server roles. > > Wietse >
Re: authenticate o365 users with postfix without smtp auth
our users send/receive via o365. the last mile o365->recipient should go through our service like o365->postfix->recipient here, o365 does not offer smtp auth against postfix. Am Sonntag, 16. Juni 2019 schrieb @lbutlr : > On 16 Jun2019, at 09:46, Stefan Bauer wrote: >> some of our users use o365 but would like to use our service for outgoing mails. we are offering smtp sending services. integrating our service in o365 is tricky, as one can only specify a smarthost but microsoft does not offer any kind of authentication for smarthosts. > > You can, and should (and I would say MUST) authenticate your users. You do not need Microsoft to authenticate them. > >> so i'm asking if someone also noticed that and can recommend best practice to allow o365 to relay via postfix without available sasl authentication in a secure way. > > Why would o365 be relaying via your server? > > User connects to your server. > User authenticates and passes authentication > User sends email > > Where is 0365 involved at all? > > > > > — > > >
Re: authenticate o365 users with postfix without smtp auth
some of our users use o365 but would like to use our service for outgoing mails. we are offering smtp sending services. integrating our service in o365 is tricky, as one can only specify a smarthost but microsoft does not offer any kind of authentication for smarthosts. so i'm asking if someone also noticed that and can recommend best practice to allow o365 to relay via postfix without available sasl authentication in a secure way. I'm just baffled about microsofts move to remove authentication in there exchange cloud version and howto work around that in a reasonable way. Am Sonntag, 16. Juni 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > On Sun, Jun 16, 2019 at 04:00:38PM +0200, Stefan Bauer wrote: > >> We are running a small smtp relay service with postfix for authenticated >> users. Unfortunately office 365 does not offer any smtp authentication >> mechanism when sending mails via connectors to smarthosts. > > There's a giant gap between the first sentence and the second. > You'll need to explain the use-case in considerably more detail. > > Why does Office365 elect to use your relay at all? Do they limit > the traffic so routed to just the authorized users? Are you sure > they can't/won't use a SASL login or TLS client cert to authenticate, > in this context. > > There's no magic, Postfix can only authorize based on IP address, > SASL or TLS auth, possibly further constrained by sender address > (which is never sufficient in isolation). > > -- > Viktor. >
authenticate o365 users with postfix without smtp auth
Hi, we are running a small smtp relay service with postfix for authenticated users. Unfortunately office 365 does not offer any smtp authentication mechanism when sending mails via connectors to smarthosts. how could one protect smtp submission in another way? without authentication, everyone from MS ip ranges with valid sender address could relay through our service. i dont like to open our service 'blind' to MS ip ranges. Ideas/Thoughts are very welcome. Stefan
Re: re-route mails on demand during block of ip address
Hi Noel, thank you for your reply. You know, in real world, ips/ranges get blocked from time to time and i would like to be ready for this and not rely on others :) The workaround looks indeed crappy - i wonder how others handle this situation in "bigger" setups? I'm currently having 7000-8000 mails / day. Stefan Am Fr., 31. Mai 2019 um 18:37 Uhr schrieb Noel Jones : > On 5/31/2019 1:48 AM, Stefan Bauer wrote: > > Hi, > > > > I'm running a pair of postfix-servers in different data-centers > > (different ip networks) for outgoing-only delivery. once in a while > > my providers /22 appear on public blacklists, so mails from my nodes > > also gets rejected. > > > > For this, i have now a third backup-instance in another data center > > that is not visible to my users and only fairly with dummy mails > > used to keep reputation up and good. Howto re-route traffic on > > demand with postfix in case, ip-networks get blocked again? > > > > How do others handle this? > > > > Thank you. > > > > Stefan > > > Much better to send all your mail via the ISP that doesn't get their > whole space blocked, rather than a crappy workaround. > > For a crappy workaround, you can use smtp_reply_filter to turn 5xx > rejects due to blacklists into 4xx temp failures, then use > smtp_fallback_relay to send the temp failures to your backup server. > This will send other mail to the backup server, such as greylisted > mail or mail that temp fails for unrelated reasons. Try to make your > reply filter narrow enough that it doesn't transform rejects for > non-rbl reasons, such as unknown recipient. > > http://www.postfix.org/postconf.5.html#smtp_reply_filter > http://www.postfix.org/postconf.5.html#smtp_fallback_relay > > > >-- Noel Jones >
re-route mails on demand during block of ip address
Hi, I'm running a pair of postfix-servers in different data-centers (different ip networks) for outgoing-only delivery. once in a while my providers /22 appear on public blacklists, so mails from my nodes also gets rejected. For this, i have now a third backup-instance in another data center that is not visible to my users and only fairly with dummy mails used to keep reputation up and good. Howto re-route traffic on demand with postfix in case, ip-networks get blocked again? How do others handle this? Thank you. Stefan
retrigger MX lookup for undeliverable mails in mailqueue
Hi, our outgoing mails sometimes end up undeliverable in postfix queue and bounce back after 5 days, when remote sites change MX entries and postfix has the old informations. It seems that postfix is not doing another round of lookups when destination MX was already discoverd for remote domain which makes also sense. Are there workarounds available to re-initiate another MX-lookup for a recipient in mailqueue when it is undeliverable? any other help is also great. thank you. Stefan
disable logging of header_checks FILTER action
hi, smtp_header_checks = pcre:/etc/postfix/header_chk /^Subject: .*test.*/ FILTER test: Postfix then logs: Jan 30 12:44:16 mx2 postfix/cleanup[19243]: 096B95EAE2: filter: header Subject: some text test from mail-cloud-01.asdfasdf.tld[1.2.3.4];(...) How to disable logging of this events? I simply do not want to have sensitive informations (subject) in postfix logs. Stefan
smtp_tls_security_level = dane but have encrypt as fallback
Hi, we would like to go the next step, enable smtp_tls_security_level = dane. Currently we have encrypt site-wide. But in cases where remote sites do not have published key material, the fallback is may with dane, which is a step back in terms of security and not wanted. How can we specify: 1, Always use at least encrypt 2, When TLSA-records are found and valid, use only this to encrypt 3, When no TLSA-records are found or the ones found can not be used, fall back to encrypt, if not possible, fail. *Stefan*
Re: address_verify_negative_refresh_time = 30m is ignored
Thank you Wietse for taking the time to explain things. I really appreciate this. now all is clear. Am Freitag, 25. Januar 2019 schrieb Wietse Venema : > Stefan Bauer: >> thank you. seems to be that >> >> if address_verify_negative_refresh_time = 30m, the next attempt to reach a >> specific recipient that is negative in cache, will still get the "old" >> answer from cache if it is not expired by >> address_verify_negative_expire_time. that is default 3d. > > I just looked things up (I wrote this code more than 10 years ago!), > and I conclude that you misunderstand the difference between > EXPIRATION time and REFRESH time. > > As long as the stored result is not expired, the stored result is > returned to smtpd. That is what expiration means. > > After the non-expired result is returned to smtpd, a refresh may > happen when the non-expired result is older than some positive > or negative refresh time. That is what refresh means. > > But it would be stupid to block the smtpd while the refresh for a > NON-EXPIRED result is in progress, because then you might just as > well have a very short expire time. > > Wietse > > >
Re: address_verify_negative_refresh_time = 30m is ignored
thank you. seems to be that if address_verify_negative_refresh_time = 30m, the next attempt to reach a specific recipient that is negative in cache, will still get the "old" answer from cache if it is not expired by address_verify_negative_expire_time. that is default 3d. so in my case, postfix was doing a new verify, but reported the old results from cache. I was expecting that postfix would always do a new probe and not just handing out old results even though it lears right after this, new results. Am Fr., 25. Jan. 2019 um 16:33 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Jan 25 15:31:14 mx2 postfix/smtpd[10117]: NOQUEUE: reject: RCPT from > > opsmail.colo.comodo.com[91.209.196.133]: 550 5.1.1 > > > address: host IP[IP] said: 550 5.1.1 > address rejected: User unknown in virtual mailbox table (in reply to > > RCPT TO command); from= > > to= > helo= > > Jan 25 15:31:14 mx2 postfix/smtp[10124]: 2CFE27E3A2: > > to= > delays=0/0.01/0.21/0.03, dsn=2.1.5, status=deliverable (250 2.1.5 Ok) > > The second logfile record shows that a new probe was sent with queue > ID 2CFE27E3A2 (the old result had expired, or it was older than > half the expiration time), and the probe result was 'deliverable'. > > If the old result was expired, then it would be a surprise that the > expired result was returned to smtpd. Normally, an expired result > is supposed to be ignored, as if the result did not exist. > > If the result was older than half the expiration time but not > expired, then it would be OK to return the old probe result to > smtpd. > > > I dont see a veify request at 15:31 at the remote site. why is postfix > > still caching verify results but report instead after client was > > rejected, that the address is deliverable? > > The probe had queue ID 2CFE27E3A2. Look in your mail logfile. > > Wietse >
address_verify_negative_refresh_time = 30m is ignored
hi, we have address_verify_negative_refresh_time = 30m active (root@mx2:/var/lib/postfix# postconf -n | grep verify address_verify_negative_refresh_time = 30m) but the verify behavior is strange. Jan 23 21:15:21 mx2 postfix/postscreen[Jan 25 15:31:14 mx2 postfix/smtpd[10119]: NOQUEUE: reject: RCPT from opsmail.colo.comodo.com[91.209.196.133]: 550 5.1.1 to= Jan 25 15:31:14 mx2 postfix/smtpd[10117]: NOQUEUE: reject: RCPT from opsmail.colo.comodo.com[91.209.196.133]: 550 5.1.1 to= Jan 25 15:31:14 mx2 postfix/smtp[10124]: 2CFE27E3A2: to=
Re: detecting TLS issues in delivery - Cannot start TLS: handshake failure
"Some sites may blacklist you when you are probing them too often (a probe is an SMTP session that does not deliver mail), or when you are probing them too often for a non-existent address. This is one reason why you should use sender address verification sparingly, if at all, when your site receives lots of email." http://www.postfix.org/ADDRESS_VERIFICATION_README.html#limitations As our user may do mailings from time to time, i do not want to get bad reputation by probing microsoft,yahoo whatever too often. :) for remote site, i see no difference between sender and recipient verification. in both cases, im doing a 'half delivery' of a mail. Am Mittwoch, 16. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 16, 2019, at 9:56 AM, Wietse Venema wrote: >> >>> reject_unverified_recipient is no option as remote sites don't like >>> probing/verify requests. After rechecking, i had a typo in my regex. >> >> reject_unverified RECIPIENT, not reject_unverified_SENDER > > Specifically, because it would be used on the submission port or > only for clients in trusted networks, it would not be open to abuse > by random strangers. The same users allowed to send email to the > remote site, are the ones who would initially trigger a verification > probe occasionally as part of submitting an outbound message. > > It is fairly safe, and should not raise any issue with remote > receiving systems. You can monitor your logs for signs of > misuse by trusted clients. > > -- > Viktor. > >
Re: detecting TLS issues in delivery - Cannot start TLS: handshake failure
reject_unverified_recipient is no option as remote sites don't like probing/verify requests. After rechecking, i had a typo in my regex. Damn! It was working as documented. Sorry. Am Mi., 16. Jan. 2019 um 13:17 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > how can the following error be detected and an instant bounce/reject will > > be send to the sender? > > > > -- 880 Kbytes in 3 Requests. > > root@mx1:~# mailq > > -Queue ID- --Size-- Arrival Time -Sender/Recipient--- > > A97288008B 776694 Sun Jan 13 13:14:29 sender@sender > > (Cannot start TLS: handshake > > failure) > > http://www.postfix.org/postconf.5.html#reject_unverified_recipient. > > > Jan 15 14:23:01 mx1 smtp[5985]: SSL_connect error to > recipient.tld[ip]:25: > > -1 > > Jan 15 14:23:01 mx1 smtp[5985]: warning: TLS library problem: > > error:141A318A:SSL routines:tls_process_ske_dhe:dh key too > > small:../ssl/statem/statem_clnt.c:1472: > > Jan 15 14:23:01 mx1 smtp[5985]: A97288008B: to=, > > relay=recipient.tld[ip]:25, delay=173312, delays=173282/15/15/0, > dsn=4.7.5, > > status=deferred (Cannot start TLS: handshake failure) > > > > smtp_delivery_status_filter does not seem to have any effect. > > Then you made a mistake. Which mistake? Insufficient data. > > Wietse >
detecting TLS issues in delivery - Cannot start TLS: handshake failure
Hi, how can the following error be detected and an instant bounce/reject will be send to the sender? -- 880 Kbytes in 3 Requests. root@mx1:~# mailq -Queue ID- --Size-- Arrival Time -Sender/Recipient--- A97288008B 776694 Sun Jan 13 13:14:29 sender@sender (Cannot start TLS: handshake failure) recipient@recipient Jan 15 14:23:01 mx1 smtp[5985]: SSL_connect error to recipient.tld[ip]:25: -1 Jan 15 14:23:01 mx1 smtp[5985]: warning: TLS library problem: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:1472: Jan 15 14:23:01 mx1 smtp[5985]: A97288008B: to=, relay=recipient.tld[ip]:25, delay=173312, delays=173282/15/15/0, dsn=4.7.5, status=deferred (Cannot start TLS: handshake failure) smtp_delivery_status_filter does not seem to have any effect. thank you. Stefan
Re: tls_high_cipherlist with !SEED is ignored
now i got it. sorry and thank you for your help. Am Dienstag, 15. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 15, 2019, at 8:39 AM, Stefan Bauer wrote: >> >> -o smtpd_tls_mandatory_ciphers=high >> -o tls_preempt_cipherlist=yes >> -o tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S >> HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA > > Instead, try: > > master.cf: > submission inet ... smtpd > ... > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_mandatory_ciphers=high > -o smtpd_tls_exclude_ciphers=$msa_exclude_ciphers > > main.cf: > msa_exclude_ciphers = SEED > > See: http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers > > -- > Viktor. > >
Re: tls_high_cipherlist with !SEED is ignored
I just want to set allowed ciphers but can not enforce encryption generally. this seems to be a limitation and not possible right? Am Dienstag, 15. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 15, 2019, at 8:39 AM, Stefan Bauer wrote: >> >> -o smtpd_tls_mandatory_ciphers=high >> -o tls_preempt_cipherlist=yes >> -o tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S >> HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA > > Instead, try: > > master.cf: > submission inet ... smtpd > ... > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_mandatory_ciphers=high > -o smtpd_tls_exclude_ciphers=$msa_exclude_ciphers > > main.cf: > msa_exclude_ciphers = SEED > > See: http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers > > -- > Viktor. > >
tls_high_cipherlist with !SEED is ignored
Nessus reports for example TLS_RSA_WITH_SEED_CBC_SHA as weak on our submission port. So i was using the following to disable all SEED ciphers on submission port but it has no effect: -o smtpd_tls_mandatory_ciphers=high -o tls_preempt_cipherlist=yes -o tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-S HA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA after postfix restart, nmap --script ssl-enum-ciphers -p 587 mailserver still reports SEED ciphers: $ nmap --script ssl-enum-ciphers -p 587 mailserver | grep SEED | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A What am i missing?
Re: DSN behavior unclear - clarification needed
Awesome. Thank you. That did the trick. Am Di., 15. Jan. 2019 um 13:22 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > i would like that postfix always sends DSN, when requested by client and > > mail got forwarded to next-hop / final destination. > > Postfix implements a published RFC, and according to that RFC, > Postfix will send a 'relayed' DSN if: > > 1 - The sender requested DSN notification. > > And: > > 2 - The next-hop MTA does not announce DSN support, or you turn off > DSN support (smtp_discard_ehlo_keywords = dsn, silent-discard). > > Additionally, you can tweak the SMTP conversation with > smtpd_command_filter, smtp_reply_filter, and smtp_delivery_status_filter. > There are examples in the documentation of those parameters. > > Wietse >
DSN behavior unclear - clarification needed
Hi, i would like that postfix always sends DSN, when requested by client and mail got forwarded to next-hop / final destination. Thats works on some recipients, but not on all. postfix always sends DSN on specific destinations (e.g. web.de) : delivery via mx-ha02.web.de[212.227.17.8]:25: 250 Requested mail action okay, completed: id=1N0YD0-1hUYlq3qCq-00wNxk But when mail is send to some other foreign postfix servers, the foreign mailserver sends DSN. How can we specifiy, that only "our" postfix server sends DSN. Reason is, we have custom bounce messages and would like to only present our users our custom DSN text. Thank you. Stefan
Re: bypass policy server in recipient_restrictions when subject contains string
Thank you. That explains it! Am Sa., 5. Jan. 2019 um 15:03 Uhr schrieb Benny Pedersen : > Stefan Bauer skrev den 2019-01-05 14:08: > > > tls_whitelist_check unix- - n - - > > smtp > >-o header_checks= > >-o smtp_header_checks= > >-o > > smtpd_recipient_restrictions=check_policy_service,unix:private/policy > >-o sender_dependent_default_transport_maps= > >-o smtpd_relay_restrictions= > > smtpd cant be overrided in smtp master.cf :=) > > it can, but it have no effect, sorry cant help more >
Re: bypass policy server in recipient_restrictions when subject contains string
Seems to have no effect for unknown reasons. policy service is not called. Tried: master.cf tls_whitelist_check unix- - n - - smtp -o header_checks= -o smtp_header_checks= -o smtpd_recipient_restrictions=check_policy_service,unix:private/policy -o sender_dependent_default_transport_maps= -o smtpd_relay_restrictions= header_checks in main.cf: /^Subject: .*/ FILTER tls_whitelist_check: mail.log reports: Jan 5 14:00:09 mx1 postfix/cleanup[31559]: 3FE0A8062A: filter: header Subject: test from mail1.remote.tld[1.2.3.4]; from= to= proto=ESMTP helo=: tls_whitelist_check: mail gets delivered, but policy service is not used/called. What am i missing? Am Sa., 5. Jan. 2019 um 11:05 Uhr schrieb Stefan Bauer < cubew...@googlemail.com>: > Understood. Would it be possible to have header_checks in main.cf that > send mails with special subject with FILTER to smtp process that did not > have policy service as option > > and all other mails (/.*/) > > also with FILTER to smtp process with policy service? > > this way i can bypass policy service with special subject. > > Am Freitag, 4. Januar 2019 schrieb Bill Cole < > postfixlists-070...@billmail.scconsult.com>: > > On 4 Jan 2019, at 10:36, Stefan Bauer wrote: > > > >> Would it be possible to have FILTER as action in policy server > > > > Yes, but FILTER behaves as documented in the access(5) man page. The > first 5 words there describing what FILTER does are critical, but you > should read it all... > > > >> (in > >> recipient_restrictions) and send it to smtp process that uses > header_checks > >> do have mailroute based on subject? > > > > There can be NO WAY to exempt a message from policy that would apply at > RCPT time with facts that cannot be known until end-of-DATA time. Postfix > cannot modify the basic constraints of non-quantum causality or the arrow > of time or tell SMTP clients to re-order the fixed command sequence of SMTP. > > > > If you want to make any decisions about a message based on a header, you > must do that with a tool (header_checks, milter, content_filter, or > post-delivery backend) that has access to the message data because it > operates at end-of-DATA or after queueing. > >
Re: bypass policy server in recipient_restrictions when subject contains string
Understood. Would it be possible to have header_checks in main.cf that send mails with special subject with FILTER to smtp process that did not have policy service as option and all other mails (/.*/) also with FILTER to smtp process with policy service? this way i can bypass policy service with special subject. Am Freitag, 4. Januar 2019 schrieb Bill Cole < postfixlists-070...@billmail.scconsult.com>: > On 4 Jan 2019, at 10:36, Stefan Bauer wrote: > >> Would it be possible to have FILTER as action in policy server > > Yes, but FILTER behaves as documented in the access(5) man page. The first 5 words there describing what FILTER does are critical, but you should read it all... > >> (in >> recipient_restrictions) and send it to smtp process that uses header_checks >> do have mailroute based on subject? > > There can be NO WAY to exempt a message from policy that would apply at RCPT time with facts that cannot be known until end-of-DATA time. Postfix cannot modify the basic constraints of non-quantum causality or the arrow of time or tell SMTP clients to re-order the fixed command sequence of SMTP. > > If you want to make any decisions about a message based on a header, you must do that with a tool (header_checks, milter, content_filter, or post-delivery backend) that has access to the message data because it operates at end-of-DATA or after queueing. >
Re: policy server, TLS only exeptions and restrictions
great idea, but recipient verification is not something, remote servers like.really like. Am Freitag, 4. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 4, 2019, at 9:10 AM, Matus UHLAR - fantomas wrote: >> >> this looks to me that you search for connection between smtpd_recipient_restrictions >> and smtp_tls_policy_maps, and there is none. >> >> the "check_policy_service private/policy" communicates via unix socket >> private/policy (apparetly in postfix directory) to external program that >> tells smtpd what to do. >> >> if you want your policy server to return dunno for sending domain >> "remote-site.de", your policy server must look to the /etc/postfix/tls/finance >> table for the remote-site.de domain. >> >> the policy server doesn't look to your "smtp_tls_policy_maps" settings, >> usually it does not read postfix configuration at all. > > This is where recipient verification has an advantage over a policy > service. For SASL authenticated users, who can relay outbound, the > OP could replace the policy service with a recipient verification > callout: > >smtpd_relay_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination > >smtpd_recipient_restrictions > permit_auth_destination, > reject_unverified_recipient > > This *is* sensitive to outbound TLS policy, because recipient > verification uses outbound SMTP connections to probe for TLS > support, and will fail where TLS is mandated and not available. > > Of course static configuration that are reflected in both the > policy service and the SMTP TLS policy yield more predictable, > if not always up to date behaviour. > > -- > Viktor. > >
Re: bypass policy server in recipient_restrictions when subject contains string
Would it be possible to have FILTER as action in policy server (in recipient_restrictions) and send it to smtp process that uses header_checks do have mailroute based on subject? Am Fr., 4. Jan. 2019 um 16:08 Uhr schrieb Bill Cole < postfixlists-070...@billmail.scconsult.com>: > On 4 Jan 2019, at 9:36, Stefan Bauer wrote: > > > is there a way to bypass policy server in smtp_recipient_restrictions, > > in > > case, subject contains special string? > > No. As documented, smtp_recipient_restrictions is evaluated for each > RCPT command, all of which occur before the DATA command, which is when > the SMTP server can examine message data (including message headers.) >
bypass policy server in recipient_restrictions when subject contains string
Hi, is there a way to bypass policy server in smtp_recipient_restrictions, in case, subject contains special string? smtpd_recipient_restrictions = check_policy_service unix:private/policy header_checks: /^Subject: .*string.*/ FILTER no-policy-service: header_checks could reroute by subject but seems to kick in too late :/ Stefan
Re: policy server, TLS only exeptions and restrictions
Understood. Thank you. Am Fr., 4. Jan. 2019 um 15:11 Uhr schrieb Matus UHLAR - fantomas < uh...@fantomas.sk>: > On 04.01.19 14:44, Stefan Bauer wrote: > >we have enforced TLS to all remote sites and have appropriate tls policy > >server, that checks if TLS is avail before accepting mails. That works as > >expected. we also only accept users with auth. > > > >smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated > >reject_unauth_destination > > > >smtpd_recipient_restrictions = check_policy_service unix:private/policy > > > >policy server returns dunno or defer... > > > >Now the problem: > > > >for some destinations, we are aware, that TLS fails, so we skip checking > >and set "may" policy for specific users/destinations. However this > settings > >seems to have no effect anymore, when we enable check_policy_service. > > > >master.cf (snippet): > >finance unix - - n - - smtp > >smtp_tls_policy_maps=hash:/etc/postfix/tls/finance > > > >tls/finance: > >remote-site.de may > > > >policy server responds with defer and custom smtp_tls_policy_maps are > >ignored. > > > >Howto work around this? > > this looks to me that you search for connection between > smtpd_recipient_restrictions > and smtp_tls_policy_maps, and there is none. > > the "check_policy_service private/policy" communicates via unix socket > private/policy (apparetly in postfix directory) to external program that > tells smtpd what to do. > > if you want your policy server to return dunno for sending domain > "remote-site.de", your policy server must look to the > /etc/postfix/tls/finance > table for the remote-site.de domain. > > the policy server doesn't look to your "smtp_tls_policy_maps" settings, > usually it does not read postfix configuration at all. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Nothing is fool-proof to a talented fool. >
policy server, TLS only exeptions and restrictions
Hi, we have enforced TLS to all remote sites and have appropriate tls policy server, that checks if TLS is avail before accepting mails. That works as expected. we also only accept users with auth. smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_recipient_restrictions = check_policy_service unix:private/policy policy server returns dunno or defer... Now the problem: for some destinations, we are aware, that TLS fails, so we skip checking and set "may" policy for specific users/destinations. However this settings seems to have no effect anymore, when we enable check_policy_service. master.cf (snippet): finance unix - - n - - smtp smtp_tls_policy_maps=hash:/etc/postfix/tls/finance tls/finance: remote-site.de may policy server responds with defer and custom smtp_tls_policy_maps are ignored. Howto work around this? thank you. Stefan
Re: detect fake mx, tls security encrypt
Hi Robert, thanks. already saw that but i dont want to bother remote sites with a 'full verify'. still like the policy server approach. should be no big thing for a coder - familiar with perl. Am Samstag, 22. Dezember 2018 schrieb Robert Schetterer : > Am 22.12.18 um 07:55 schrieb Stefan Bauer: >> >> nights later, a better approach seems to have a policy service that does the tls pre-checking. > > > long time ago i wrote this > > https://blog.sys4.de/recipient-verification-tls-mandatory-modus-en.html > > perhaps it helps > >> >> Something like this already around? ( i'm no coder but want to sponsor that if someone can do it) pm please >> >> Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org <mailto:postfix-us...@dukhovni.org>>: >> >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer mailto:cubew...@googlemail.com>> wrote: >> >> >> >> I'm aware of such exceptions but I don't like to set them. Our policy is safe or not at all via mail. >> > >> > That policy has a cost. You don't like the cost, but there it is... >> > >> >> I would like to have a setting like do not try next mx, >> >> if first mx lacks tls support. it assumes that if tls is >> >> not avail on primary it will for sure also not be avail >> >> on second and third. >> > >> > Sorry, Postfix does not and will not do that. Data-mine your logs >> > for deliveries that fall back to a dead MX host (connection failure >> > and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d" >> > part of the log entry, e.g. >> > >> > delays=263861/0.01/60/0, dsn=4.4.1, status=deferred >> > (connect to : Operation timed out) >> > >> > Then, if you refuse to ever deliver in the clear, reject mail to >> > the domain. >> > >> > transport: >> > example.com <http://example.com> error:5.1.2:Destination domain does not support STARTTLS >> > >> > -- >> > -- >> > Viktor. >> > > > > -- > [*] sys4 AG > > http://sys4.de, +49 (89) 30 90 46 64 > Schleißheimer Straße 26/MG, 80333 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein >
Re: detect fake mx, tls security encrypt
nights later, a better approach seems to have a policy service that does the tls pre-checking. Something like this already around? ( i'm no coder but want to sponsor that if someone can do it) pm please Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer wrote: >> >> I'm aware of such exceptions but I don't like to set them. Our policy is safe or not at all via mail. > > That policy has a cost. You don't like the cost, but there it is... > >> I would like to have a setting like do not try next mx, >> if first mx lacks tls support. it assumes that if tls is >> not avail on primary it will for sure also not be avail >> on second and third. > > Sorry, Postfix does not and will not do that. Data-mine your logs > for deliveries that fall back to a dead MX host (connection failure > and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d" > part of the log entry, e.g. > > delays=263861/0.01/60/0, dsn=4.4.1, status=deferred > (connect to : Operation timed out) > > Then, if you refuse to ever deliver in the clear, reject mail to > the domain. > > transport: > example.com error:5.1.2:Destination domain does not support STARTTLS > > -- > -- > Viktor. >
Re: detect fake mx, tls security encrypt
thats a nice approach! thank you. will test. Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer wrote: >> >> I'm aware of such exceptions but I don't like to set them. Our policy is safe or not at all via mail. > > That policy has a cost. You don't like the cost, but there it is... > >> I would like to have a setting like do not try next mx, >> if first mx lacks tls support. it assumes that if tls is >> not avail on primary it will for sure also not be avail >> on second and third. > > Sorry, Postfix does not and will not do that. Data-mine your logs > for deliveries that fall back to a dead MX host (connection failure > and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d" > part of the log entry, e.g. > > delays=263861/0.01/60/0, dsn=4.4.1, status=deferred > (connect to : Operation timed out) > > Then, if you refuse to ever deliver in the clear, reject mail to > the domain. > > transport: > example.com error:5.1.2:Destination domain does not support STARTTLS > > -- > -- > Viktor. >
Re: detect fake mx, tls security encrypt
I'm aware of this exeptions but i dont like to set them. our policy is safe
or not at all via mail.
i would like to have a setting like do not try next mx, if first mx lacks
tls support. it assumes that if tls is not avail on primary it will for
sure also not be avail on second and third.
Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>> On Dec 20, 2018, at 12:42 PM, Stefan Bauer
wrote:
>>
>> I use smtp_tls_security_level = encrypt
>
> The cost of that choice is that you must also have:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtp_tls_policy_maps = ${indexed}tls-policy
>
> and be prepared to watch your logs and add manual exceptions:
>
> tls-policy:
> # Non-mandatory TLS for domains that don't (yet?) have
> # working STARTTLS. Perhaps "none" rather than "may" in
> # some cases.
> #
> example.net may
> ...
>
> --
> Viktor.
>
>
detect fake mx, tls security encrypt
Hi, i use smtp_tls_security_level = encrypt - if remote site have mx like mx 10 mail1 without tls mx 100 mail2 fake-mx with no open port postfix detects lack of tls on mx10goes to mx100 and waits maximal_queue_lifetime. i don't like fake mx as they create a long delay. i could reduce queue lifetime but in general thats bad for real systems with temp issues. how do you handle this? Stefan
Re: dnsbl postscreen - not blocking
the threshold is at default, so 1. but the dns timeout, Wietse mentioned, might be the real cause. gonna check manuals, if this is configurable. Thank you. Am Mittwoch, 19. Dezember 2018 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > On Wed, Dec 19, 2018 at 02:00:34PM +0100, Stefan Bauer wrote: > >> Dec 19 13:04:36 mx1 postfix/postscreen[4770]: CONNECT from >> [209.85.166.196]:52168 to [public-ip]:25 >> Dec 19 13:04:42 mx1 postfix/dnsblog[4774]: addr 209.85.166.196 listed by >> domain dnsbl.sorbs.net as 127.0.0.6 >> Dec 19 13:04:42 mx1 postfix/postscreen[4770]: PASS NEW >> [209.85.166.196]:52168 >> Dec 19 13:04:42 mx1 postfix/smtpd[4778]: connect from >> mail-it1-f196.google.com[209.85.166.196] >> >> why did google pass postscreen even though its listed in one of the RBL? >> >> postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 >> b.barracudacentral.org*1 dnsbl.sorbs.net*1 >> postscreen_blacklist_action = drop >> postscreen_dnsbl_action = enforce >> >> Am i missing something obvious? > > What is the minimum weight you require for an RBL block? The sorbs > RBL has weight 1, perhaps you require 2 or more. > > http://www.postfix.org/postconf.5.html#postscreen_dnsbl_threshold > > You've not posted your complete "postconf -n" output, so it is all > conjectural. > > -- > Viktor. >
Re: ignore SASL/Auth to specific server (internal exchange relay)
thank you for your help folks! Yes that indeed helped to understand the process! Am Mi., 12. Dez. 2018 um 20:48 Uhr schrieb Daniel Miller : > Not wanting to get in the way of the experts but this may help: > > An oversimplified view of the transport map is it tells Postfix what line > in master.cf to use for a given recipient domain (or full address). > There's only one transport map but it can have several lines for individual > decisions. > > Wietse's email told you to perform a command-line test to verify your > transport map is setup correctly. So do that first. > > The definitions in master.cf tell Postfix where to listen and where to > send the message. So with an explicit transport mapping, using master.cf > you provide explicit overrides to the defaults or global settings from > main.cf. So if the only "special" behavior you need for the exchange > transport is no sasl: > exchange unix - - n - - smtp > -o smtp_sender_dependent_authentication=no > > Daniel > > > On 12/11/2018 1:40 PM, Stefan Bauer wrote: > > thank you for your help! > > If i understood you correctly, i set in transport: > > domain1.deexchange: > > In master.cf > > exchange unix - - n - - smtp > -o smtp_sender_dependent_authentication=no > -o transport_maps=hash:/etc/postfix/transport_internal > > And in transport_internal > > domain1.desmtp:192.168.124.5:2525 > > but this way, postfix is doing a MX-lookup for domain1.de and not > honoring transport_internal as it seems. > > Is this basically the right path? > > > Am Di., 11. Dez. 2018 um 21:48 Uhr schrieb Viktor Dukhovni < > postfix-us...@dukhovni.org>: > >> > On Dec 11, 2018, at 3:41 PM, Stefan Bauer >> wrote: >> > >> > Can you recommend appropriate manual(s)? I dont understand what you >> mean with separate transport. >> >> http://www.postfix.org/master.5.html >> http://www.postfix.org/transport.5.html >> http://www.postfix.org/ADDRESS_REWRITING_README.html >> http://www.postfix.org/FILTER_README.html#advanced_filter >> ( Advanced content filter: sending unfiltered mail to the content >> filter ) >> >> Also the Postfix book by Patrick Koetter and Ralf Hildebrandt. >> >> -- >> Viktor. >> >>
Re: ignore SASL/Auth to specific server (internal exchange relay)
i already have a transport_maps in main.cf in place: transport_maps=hash:/etc/postfix/transport domain1.deexchange: How can i set another transport_maps setting in main.cf as you recommend? Am Mi., 12. Dez. 2018 um 00:29 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > On Dec 11, 2018, at 4:40 PM, Stefan Bauer > wrote: > > > > exchange unix - - n - - smtp > > -o smtp_sender_dependent_authentication=no > > -o transport_maps=hash:/etc/postfix/transport_internal > > No the "transport_maps" setting goes in main.cf. Transport > lookups are global. > > See: http://www.postfix.org/OVERVIEW.html > > -- > Viktor. > >
Re: ignore SASL/Auth to specific server (internal exchange relay)
thank you for your help! If i understood you correctly, i set in transport: domain1.deexchange: In master.cf exchange unix - - n - - smtp -o smtp_sender_dependent_authentication=no -o transport_maps=hash:/etc/postfix/transport_internal And in transport_internal domain1.desmtp:192.168.124.5:2525 but this way, postfix is doing a MX-lookup for domain1.de and not honoring transport_internal as it seems. Is this basically the right path? Am Di., 11. Dez. 2018 um 21:48 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > On Dec 11, 2018, at 3:41 PM, Stefan Bauer > wrote: > > > > Can you recommend appropriate manual(s)? I dont understand what you mean > with separate transport. > > http://www.postfix.org/master.5.html > http://www.postfix.org/transport.5.html > http://www.postfix.org/ADDRESS_REWRITING_README.html > http://www.postfix.org/FILTER_README.html#advanced_filter > ( Advanced content filter: sending unfiltered mail to the content filter > ) > > Also the Postfix book by Patrick Koetter and Ralf Hildebrandt. > > -- > Viktor. > >
Re: ignore SASL/Auth to specific server (internal exchange relay)
Can you recommend appropriate manual(s)? I dont understand what you mean with separate transport. Am Di., 11. Dez. 2018 um 21:20 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > To use host-specific rather than sender-dependent authentication, > you'll need a separate transport for the relay(s) in question, > with "smtp_sender_dependent_authentication = no" for that > transport. > > > On Dec 11, 2018, at 2:37 PM, Stefan Bauer > wrote: > > > > I dont see a way to have AUTH to all of our relayhosts but not for > this internal hosts. > > > > sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps > > smtp_sender_dependent_authentication = yes > > smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth > > smtp_sasl_auth_enable = yes > > smtp_tls_security_level = may > > smtp_sasl_security_options = noanonymous > > > > root@postgate01:/etc/postfix# more relayhost_maps > > @domain1.de [securerelay.tld]:25 > > @domain2.de [securerelay.tld]:25 > > > > -- > Viktor. > >
Re: ignore SASL/Auth to specific server (internal exchange relay)
I dont see a way to have AUTH to all of our relayhosts but not for this internal hosts. sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps smtp_sender_dependent_authentication = yes smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth smtp_sasl_auth_enable = yes smtp_tls_security_level = may smtp_sasl_security_options = noanonymous root@postgate01:/etc/postfix# more relayhost_maps @domain1.de [securerelay.tld]:25 @domain2.de [securerelay.tld]:25 root@postgate01:/etc/postfix# more transport domain1.de smtp:192.168.124.5:2525 domain2.de smtp:192.168.124.5:2525 So howto not use AUTH at all to 192.168.124.5:2525 ? Am Di., 11. Dez. 2018 um 20:32 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > we receive mails from $world and forward them to internal exchange > server. > > > > Exchange is offering STARTTLS and AUTH > > > > root@gate01:~# telnet 192.168.124.5 2525 > > Trying 192.168.124.5... > > Connected to 192.168.124.5. > > Escape character is '^]'. > > Dec 11 19:27:18 postgate01 postfix/postscreen[583]: DISCONNECT > > [client]:57636 > > Dec 11 19:27:18 postgate01 postfix/smtp[574]: 5586D101077: to=< > > odf...@customer.de>, relay=192.168.124.5[192.168.124.5]:2525, delay=11, > > delays=1/0.02/10/0, dsn=4.7.3, status=undeliverable (SASL authentication > > failed; server 192.168.124.5[192.168.124.5] said: 535 5.7.3 > Authentication > > unsuccessful) > > > > how can we ignore AUTH and STARTTLS and just go on? > > If you don't want Postfix to send AUTH to this server, > then do not configure Postfix to send AUTH to this server. > > Woeyse >
ignore SASL/Auth to specific server (internal exchange relay)
Hi, we receive mails from $world and forward them to internal exchange server. Exchange is offering STARTTLS and AUTH root@gate01:~# telnet 192.168.124.5 2525 Trying 192.168.124.5... Connected to 192.168.124.5. Escape character is '^]'. 220 ex01 Microsoft ESMTP MAIL Service ready at Tue, 11 Dec 2018 19:07:13 +0100 ehlo cubewerk.de 250-gate01 Hello [192.168.124.251] 250-SIZE 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-X-ANONYMOUSTLS 250-AUTH NTLM 250-X-EXPS GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250-XRDST 250 XSHADOWREQUEST Postfix gets ... during address verification. Dec 11 19:27:18 postgate01 postfix/postscreen[583]: DISCONNECT [client]:57636 Dec 11 19:27:18 postgate01 postfix/smtp[574]: 5586D101077: to=< odf...@customer.de>, relay=192.168.124.5[192.168.124.5]:2525, delay=11, delays=1/0.02/10/0, dsn=4.7.3, status=undeliverable (SASL authentication failed; server 192.168.124.5[192.168.124.5] said: 535 5.7.3 Authentication unsuccessful) how can we ignore AUTH and STARTTLS and just go on? telnet shows the dialog i expect: outgoing mails get relayed through smarthost, so this is where all the client tls settings interfere i guess :/
Re: Best practice - concurrent delivery to remote sites
Thank you Wietse, wouldn't default_transport_rate_delay = 15s be a safe setting to relax the whole transport a bit? from a receivers perspective, that's something i would like to see instead of having ongoing delivery. Am Do., 6. Dez. 2018 um 14:41 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > stuff/best practice that makes the process more effective. > > > > i'm certain that remote sites prefer one way over the other. > > I don't think that there is a 'standard' policy that 'works' for > delivery from every site to every site. > > Nowadays you get a policy exception from 'big' receivers, and you > come up with transport_maps with different 'classes' of delivery > agents that are configured with different rate_delay (no concurrency), > with limited concurrency, and/or with different source IP address, > then pick the agent depending on destination. > > Or you just pay a mail sending company for doing the job. > > Wietse >
Re: Best practice - concurrent delivery to remote sites
ack. but i was looking for advices like e.g: initially defer mail delivery for lets say a minute to be able to send out a bunch of mails to same recipient in a single session instead of having 100 independant sessions. stuff/best practice that makes the process more effective. i'm certain that remote sites prefer one way over the other. Stefan Am Donnerstag, 6. Dezember 2018 schrieb Andrey Repin : > Greetings, Stefan Bauer! > > >>> we're running a small relay-service and looking for best practice to > >>> deliver mails to remote sites regarding concurrent delivery and so on. >>> >>> > >>> Sometimes, we have customers that are sending several mails per second to same recipients. >>> >>> > >>> What is best practice to handle this? >>> >>> > >>> We would like to avoid getting blacklisted or throttled by remote sites due > >>> to sending too many mails or in an non compliant way. How should this be handled/configured in postfix? >>> >>> >>> This has nothing to do with postfix itself. >>> Social issues can't be solved by technical means. >>> > >>> so far all settings are default in postfix. >>> >>> >>> > >>> thank you. >>> > >> Its no user issue. Its a real and legal use case that customers send >> several mails / second to same recipient over a long period (software tests whatever). > > Did I say anything about reality or legality? > The decision of remote host to block you is 100% social, not technical or > legal. > How do they judge you is entirely up to them, as long as you conform to > standards, you can't do anything short of communicating with the owners and > solving any arising issues as they happen. > > > -- > With best regards, > Andrey Repin > Thursday, December 6, 2018 15:00:05 > > Sorry for my terrible english... > >
Re: Best practice - concurrent delivery to remote sites
Its no user issue. Its a real and legal use case that customers send several mails / second to same recipient over a long period (software tests whatever). Am Do., 6. Dez. 2018 um 12:50 Uhr schrieb Andrey Repin : > Greetings, Stefan Bauer! > > > Hi, > > > > we're running a small relay-service and looking for best practice to > > deliver mails to remote sites regarding concurrent delivery and so on. > > > > Sometimes, we have customers that are sending several mails per second > to same recipients. > > > > What is best practice to handle this? > > > > We would like to avoid getting blacklisted or throttled by remote sites > due > > to sending too many mails or in an non compliant way. How should this be > handled/configured in postfix? > > > This has nothing to do with postfix itself. > Social issues can't be solved by technical means. > > > so far all settings are default in postfix. > > > > > thank you. > > > -- > With best regards, > Andrey Repin > Thursday, December 6, 2018 14:39:20 > > Sorry for my terrible english... > >
Best practice - concurrent delivery to remote sites
Hi, we're running a small relay-service and looking for best practice to deliver mails to remote sites regarding concurrent delivery and so on. Sometimes, we have customers that are sending several mails per second to same recipients. What is best practice to handle this? We would like to avoid getting blacklisted or throttled by remote sites due to sending too many mails or in an non compliant way. How should this be handled/configured in postfix? so far all settings are default in postfix. thank you.
Re: forwarding mail like before queue filtering to remote mta
The use case is only for mx service so there will be only incoming mail for same domain in same smtp session. I assume that remote mail servers will not combine mail delivery in same smtp session when destination domains differ (even though they have same mx) Stefan Am Mittwoch, 28. November 2018 schrieb Wietse Venema : > Stefan Bauer: >> Hi, >> >> is there a way to keep an smtp session open and do before queue filtering >> AND final delivery to remote mta? do only sent 250 if we have already >> received 250. if not send temp error. > > How would that work when one message has more than one recipient? > In different domains? When one domain accepts the message, and the > other tempfails? What status would Postfix return to the SMTP client? > >> we would like to only accept mails if we can deliver them at the same time. >> a local queue is not wanted due to privacy reasons. > > Use a proxy that accepts one recipient at a time. > > Wietse >
forwarding mail like before queue filtering to remote mta
Hi, is there a way to keep an smtp session open and do before queue filtering AND final delivery to remote mta? do only sent 250 if we have already received 250. if not send temp error. we would like to only accept mails if we can deliver them at the same time. a local queue is not wanted due to privacy reasons. Stefan
Re: cisco pix TLS is required, but was not offere STARTTLS issue
Yes and confirmed. Thank you. Setting smtp_pix_workarounds = delay_dotcrlf (so that default setting disable_esmtp has no effect) delivers mail correctly with STARTTLS. 95EB580805: enabling PIX workarounds: delay_dotcrlf for mx1.esb.de [194.77.230.139]:25 Untrusted TLS connection established to mx1.esb.de[194.77.230.139]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits) 95EB580805: to=, relay=mx1.esb.de[194.77.230.139]:25, delay=0.9, delays=0.08/0.01/0.55/0.26, dsn=2.0.0, status=sent (250 ok: Message 5896742 accepted) There might be for sure good reasons, why 'disable_esmtp' is set by default. Am Mo., 26. Nov. 2018 um 11:21 Uhr schrieb Stefan Bauer < cubew...@googlemail.com>: > Hi, > > log shows: > > enabling PIX workarounds: disable_esmtp delay_dotcrlf for mx0.esb.de > > But the specific workaround 'disable_esmtp' looks like to be the reason > for downgrading to plain smtp and disallowing any STARTTLS right? > > Am Mo., 26. Nov. 2018 um 10:20 Uhr schrieb Patrick Ben Koetter >: > >> * Stefan Bauer : >> > Dear Users, >> > >> > we trying to deliver mail to remote party with enforced encrcyption. >> > >> > 63FFB80805: TLS is required, but was not offered by host mx0.esb.de >> > [194.77.230.138] >> > >> > But looks like, remote device is announcing TLS and can handle it: >> > >> > # telnet mx0.esb.de 25 >> > Trying 194.77.230.138... >> > Connected to mx0.esb.de. >> > Escape character is '^]'. >> > 220 >> > ehlo test >> > 250-mx0.esb.de >> > 250-8BITMIME >> > 250-SIZE 52428800 >> > 250 STARTTLS >> > starttls >> > 220 Go ahead with TLS >> > >> > But the minus "-" is missing in STARTTLS correct? >> >> Look into your log and you will very likely find something that says: >> >> Cisco PIX enabled? >> >> >> > Is there a known workaround available? >> > >> > Maybe some rewrite-voodoo? >> >> Something – quite likely a Cisco ASA/PIX – manipulates the SMTP server >> banner >> and the STARTTLS capability announcement. This is what it should look >> like: >> >> 220 mail.sys4.de ESMTP Submission >> EHLO foo.sys4.de >> 250-mail.sys4.de >> 250-PIPELINING >> 250-SIZE 4096 >> 250-ETRN >> 250-STARTTLS >> 250-ENHANCEDSTATUSCODES >> 250-8BITMIME >> 250-DSN >> 250 SMTPUTF8 >> QUIT >> >> The $something removes the "ESMTP" in den server banner. Without the >> string >> "ESMTP" the mail client (read: Your Postfix smtp client) cannot know the >> remote server supports any of the Enhanced SMTP features, which includes >> STARTTLS. It *must* assume the server speak rudimentary SMTP only. >> >> Thus it uses rudimentary SMTP only, which excludes STARTTLS. And that's >> why it >> fails in the first. The missing minus "-" just adds to the dilemma. >> >> 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: cisco pix TLS is required, but was not offere STARTTLS issue
Hi, log shows: enabling PIX workarounds: disable_esmtp delay_dotcrlf for mx0.esb.de But the specific workaround 'disable_esmtp' looks like to be the reason for downgrading to plain smtp and disallowing any STARTTLS right? Am Mo., 26. Nov. 2018 um 10:20 Uhr schrieb Patrick Ben Koetter : > * Stefan Bauer : > > Dear Users, > > > > we trying to deliver mail to remote party with enforced encrcyption. > > > > 63FFB80805: TLS is required, but was not offered by host mx0.esb.de > > [194.77.230.138] > > > > But looks like, remote device is announcing TLS and can handle it: > > > > # telnet mx0.esb.de 25 > > Trying 194.77.230.138... > > Connected to mx0.esb.de. > > Escape character is '^]'. > > 220 > > ehlo test > > 250-mx0.esb.de > > 250-8BITMIME > > 250-SIZE 52428800 > > 250 STARTTLS > > starttls > > 220 Go ahead with TLS > > > > But the minus "-" is missing in STARTTLS correct? > > Look into your log and you will very likely find something that says: > > Cisco PIX enabled? > > > > Is there a known workaround available? > > > > Maybe some rewrite-voodoo? > > Something – quite likely a Cisco ASA/PIX – manipulates the SMTP server > banner > and the STARTTLS capability announcement. This is what it should look like: > > 220 mail.sys4.de ESMTP Submission > EHLO foo.sys4.de > 250-mail.sys4.de > 250-PIPELINING > 250-SIZE 4096 > 250-ETRN > 250-STARTTLS > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-DSN > 250 SMTPUTF8 > QUIT > > The $something removes the "ESMTP" in den server banner. Without the string > "ESMTP" the mail client (read: Your Postfix smtp client) cannot know the > remote server supports any of the Enhanced SMTP features, which includes > STARTTLS. It *must* assume the server speak rudimentary SMTP only. > > Thus it uses rudimentary SMTP only, which excludes STARTTLS. And that's > why it > fails in the first. The missing minus "-" just adds to the dilemma. > > 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 > >
cisco pix TLS is required, but was not offere STARTTLS issue
Dear Users, we trying to deliver mail to remote party with enforced encrcyption. 63FFB80805: TLS is required, but was not offered by host mx0.esb.de [194.77.230.138] But looks like, remote device is announcing TLS and can handle it: # telnet mx0.esb.de 25 Trying 194.77.230.138... Connected to mx0.esb.de. Escape character is '^]'. 220 ehlo test 250-mx0.esb.de 250-8BITMIME 250-SIZE 52428800 250 STARTTLS starttls 220 Go ahead with TLS But the minus "-" is missing in STARTTLS correct? Is there a known workaround available? Maybe some rewrite-voodoo? Thank you.
Re: sender_dependent_relayhost_maps with different credentials for same relayhost
Found it. Was required to modify smtp_auth to customer1.de user1:password customer2.de user2:password. Am Do., 22. Nov. 2018 um 10:22 Uhr schrieb Stefan Bauer < cubew...@googlemail.com>: > After setting > > smtp_sender_dependent_authentication = yes > > and adding additional credentials postfix rejects change with > > #root@postgate01:~# nano /etc/postfix/smtp_auth > > [securegw.intern]:25user1:password > [securegw.intern]:25user2:password > > root@postgate01:~# more /etc/postfix/relayhost_maps > @customer1.de[securegw.intern]:25 > @customer2.de[securegw.intern]:25 > > #root@postgate01:~# postmap /etc/postfix/smtp_auth > *#postmap: warning: /etc/postfix/smtp_auth.db: duplicate entry: > "[securegw.intern]:25"* > #root@postgate01:~# /etc/init.d/postfix reload && /etc/init.d/postfix > restart > #[ ok ] Reloading postfix configuration (via systemctl): postfix.service. > #[ ok ] Restarting postfix (via systemctl): postfix.service. > > I would like to route different customers to same relayhost but with > different credentials. > > Am Mo., 5. Nov. 2018 um 20:47 Uhr schrieb Wietse Venema < > wie...@porcupine.org>: > >> Stefan Bauer: >> > Hi, >> > >> > i have: >> > sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps >> > smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth >> > >> > more /etc/postfix/relayhost_maps >> > @mydomain.de[smtp.1und1.de]:587 >> > @my2domain.de [smtp.1und1.de]:587 >> > >> > more /etc/postfix/smtp_auth >> > [smtp.1und1.de]:587mydomain:mydomainpass >> > >> > How can i specify different credentials for same relayhost? >> >> smtp_sender_dependent_authentication = yes >> >> This will first index smtp_sasl_password_maps with the sender >> address, then the host, then the next-hop domain (whatever that >> happens to be). >> >> Wietse >> >> > mails from my2domain.de should be relayed through 1und1 but with its >> own >> > credentials. >> > >> > Thank you. >> > >> > Stefan >> >
Re: sender_dependent_relayhost_maps with different credentials for same relayhost
After setting smtp_sender_dependent_authentication = yes and adding additional credentials postfix rejects change with #root@postgate01:~# nano /etc/postfix/smtp_auth [securegw.intern]:25user1:password [securegw.intern]:25user2:password root@postgate01:~# more /etc/postfix/relayhost_maps @customer1.de[securegw.intern]:25 @customer2.de[securegw.intern]:25 #root@postgate01:~# postmap /etc/postfix/smtp_auth *#postmap: warning: /etc/postfix/smtp_auth.db: duplicate entry: "[securegw.intern]:25"* #root@postgate01:~# /etc/init.d/postfix reload && /etc/init.d/postfix restart #[ ok ] Reloading postfix configuration (via systemctl): postfix.service. #[ ok ] Restarting postfix (via systemctl): postfix.service. I would like to route different customers to same relayhost but with different credentials. Am Mo., 5. Nov. 2018 um 20:47 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > i have: > > sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps > > smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth > > > > more /etc/postfix/relayhost_maps > > @mydomain.de[smtp.1und1.de]:587 > > @my2domain.de [smtp.1und1.de]:587 > > > > more /etc/postfix/smtp_auth > > [smtp.1und1.de]:587mydomain:mydomainpass > > > > How can i specify different credentials for same relayhost? > > smtp_sender_dependent_authentication = yes > > This will first index smtp_sasl_password_maps with the sender > address, then the host, then the next-hop domain (whatever that > happens to be). > > Wietse > > > mails from my2domain.de should be relayed through 1und1 but with its own > > credentials. > > > > Thank you. > > > > Stefan >
Re: Best way of synchronizing configs for multiple relay servers?
i have similar case and set the first relayseever inmy pool as the one on which changes ar eonly allowed. then i do scp + service restart to the others with bash oneliner on demand. for the future i plan to check in config from any host to central svn/git repo and check frequently for changes from all nodes. svn/git repo can also be a public one for redundancy reasons (github...) if content is not sensitive. Am Mittwoch, 7. November 2018 schrieb K F : > Hi all > I'm contemplating on how I best keep all our relay servers synchronized in their config. > They are set up as round robin servers in the DNS, so they distribute the load pretty ok. > My first idea was to set up some rsync to copy the relevant directories like /etc/postfix and /etc/opendkim. > Then I need a local script on each server looking for changes, and if there is, it should restart the postfix service. > I could also just mount the folders to a specific server, but then I introduce a SPOF, which is not what I would like, and I still need something on each server to restart the postfix service if any changes are detected. > Are there any nice ready made systems for this? > I don't have any mailboxes on the servers, as they are only relays from our internal systems, so there is no need for a big system that tries to synchronize those as well. > Best regards > Kenneth >
Re: sender_dependent_relayhost_maps with different credentials for same relayhost
Thank you! Am Montag, 5. November 2018 schrieb Wietse Venema : > Stefan Bauer: >> Hi, >> >> i have: >> sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps >> smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth >> >> more /etc/postfix/relayhost_maps >> @mydomain.de[smtp.1und1.de]:587 >> @my2domain.de [smtp.1und1.de]:587 >> >> more /etc/postfix/smtp_auth >> [smtp.1und1.de]:587mydomain:mydomainpass >> >> How can i specify different credentials for same relayhost? > > smtp_sender_dependent_authentication = yes > > This will first index smtp_sasl_password_maps with the sender > address, then the host, then the next-hop domain (whatever that > happens to be). > > Wietse > >> mails from my2domain.de should be relayed through 1und1 but with its own >> credentials. >> >> Thank you. >> >> Stefan >
sender_dependent_relayhost_maps with different credentials for same relayhost
Hi, i have: sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth more /etc/postfix/relayhost_maps @mydomain.de[smtp.1und1.de]:587 @my2domain.de [smtp.1und1.de]:587 more /etc/postfix/smtp_auth [smtp.1und1.de]:587mydomain:mydomainpass How can i specify different credentials for same relayhost? mails from my2domain.de should be relayed through 1und1 but with its own credentials. Thank you. Stefan
Thank you Wietse, supporters and contributors for Postfix
We just noticed once again, that postfix is so well designed in a way, that often we did not even think of "corner cases" that are already handled by default in a way, that is in most cases exactly how is should be setup. Just picking a random setup - relaying mails to external relayhosts by sender domain but having the option to define individual transport ways. This is awesome to give the user/administrator a way to do a very fine grained mail routing. We're a "small" postfix uers (< 100.000 mails / month) but are very happy with postfix. Thank you. Stefan
Re: Monitoring amount of smtpd processes
We simply monitor established tcp sessions to smtpd port. if client flies away, tcp session does as well: lsof -i tcp:25 | grep ESTABLISHED | wc -l Am Samstag, 20. Oktober 2018 schrieb Peer Heinlein : > > > > Hi, > > we're monitoring the amount of active smtpd processes to make sure, that > we do not reach the max-proc limit from master.cf. > > If a client disconnects very early, the smtpd is still "unused" and > remains in server memory, waiting for the next connection. > > If a server was flooded with a short peak of new connections, a server > could have $process_limit instances remaining ready-to-tun in memory. > > In that situations we're seeing false positives in our monitoring. > > I can't see a way how to detect those "waiting" smtpd to cound them > differently in the process list. AFAIK there's now way (except we're > counting the number of open connections with lsof/netstat). > > What about the idea that Postfix flags those unused processes by > renaming them in the output of "ps"? > > Dovecot has a "verbose proctitle" option where pop3/imap processes are > renamed in the process list so that they're showing the logged in user, > the state of TLS, the client IP and the last IMAP-command. > > It could also be very great to have Postfix like this, showing some > informations about the connection: > > smtpd [unused/virgin] > or > smtpd [, , , ] > > Could be great for analysis and to get a quick overview about what's > going on on busy servers. > > Peer > > > -- > Heinlein Support GmbH > Schwedter Str. 8/9b, 10119 Berlin > > http://www.heinlein-support.de > > Tel: 030 / 405051-42 > Fax: 030 / 405051-19 > > Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht > Berlin-Charlottenburg, > Geschäftsführer: Peer Heinlein -- Sitz: Berlin > >
Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?
Hi Andreas, i really like postscreen. There are quite some nice tricks buikd in so thanks again for pushing me in this direction. i just bundled it now with clamav-milter so the expensive checks are only triggered when a client survives postscreen and all my additional sender/recipient checks and finally a recipient verification. i'm happy now - looks like a sane setup. Cant wait to see first spammers ;) Stefan Am Freitag, 19. Oktober 2018 schrieb Andreas Schamanek : > > On Fri, 19 Oct 2018, at 10:57, Olivier wrote: > >> So, rejecting spam during smtp-dialog is risky, that is why most resolve to some sort of quarantine, and that is when amavis comes handy. > > I agree with the 1st part but that's why I ditched Amavis! If your mail delivery setup includes anything anywhere that can call your spam filter you may not need Amavis. In my case I happen to have Procmail anyway. The filter of my choice is SpamAssassin. So, no need for anything in between. > > My recommendation is to use Postfix with postscreen including a reasonable set of dnsbls, plus a spam filter as far as possible at the end of the processing chain so that it gets called only on mail that is neither clearly ham nor spam. > > Postscreen alone allowed me to ditch ClamAV. After evaluating logs of 1 year the hit rate was about 1 of 2k messages of which 100% were flagged by SpamAssassin. Hit rate increased somewhat with the use of third-party signatures, but these detected pratically only scams and phishing attempts which IMHO need to be distinguished from the classical type of viruses. Indeed, they also caused a number of false positives. > > Again, note that my findings are based on the fact that Postfix with postscreen itself blocks the by far largest part of malicious mail. > > Of course, YMMV, > > -- > -- Andreas > > :-) > >
Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?
Thank you. So it makes sense to have all smtpd_recipient_restrictions in place, and _only if_ the client passes all checks, clamav or spamasassin is having data available to do a check. If the client fails a check, clamav/spamasassin have nothing to process. Did i get it correctly? :) Stefan Am Fr., 19. Okt. 2018 um 09:17 Uhr schrieb Carsten Rosenberg : > Have a look here: > > https://msg.wikidoc.info/index.php/Milter_operation > > Milter Protocol starts when a client connects. So you have the open > connection to clamav-milter before smtpd_recipient_restrictions is > triggered. But ClamAV can't do anything before the content is > transfered. So the performance impact should be insignificant. > > amavis-milter is just a wrapper script from milter to amavis protocol. > As long amavis is not dead this is fine. > > Carsten > > > On 19.10.18 08:59, Stefan Bauer wrote: > > Is there documentation available, at which smtp-state a milter is > > kicking in? > > I don't see a way to define at which state a milter should take action. > > > > i would lke to make sure that > > > > smtpd_milters = unix:/clamav/clamav-milter.ctl > > > > will only get triggered *after * > > > > smtpd_recipient_restrictions = > > reject_non_fqdn_sender, > > reject_non_fqdn_recipient, > > reject_unknown_sender_domain, > > reject_unknown_recipient_domain, > > > > is checked. > > > > amavis-milter seems dead. > > > > > > Am Fr., 19. Okt. 2018 um 08:33 Uhr schrieb Carsten Rosenberg > <mailto:c...@ncxs.de>>: > > > > Hi, > > > > smtp_milters and restrictions are working at the same time. > > smtpd_recipient_restriction will be evaluated at the same as the > Milter > > RCPT stage. > > > > So a ClamAV Milter should run at EOM milter stage. Anything else is > > useless ;) > > > > And in my opinion quarantine is sooo 2010. Reject (pre-queue) or > > deliver, so it's clear for sender and recipient. > > > > Have a look to amavis-milter (+spamassassin+clamav) or even rspamd. > > > > > > Carsten > > > > On 19.10.18 07:15, Stefan Bauer wrote: > > > Thank you for your feedback. Seems like smtpd_milters are also used > > > before any other check_*_access and rbl checks/header checks etc., > so > > > it's expensive this way, to pipe every mail through virus scan. > > > I'm just testing if i could plug in clamav by check_policy_service. > > > > > > Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier > > > mailto:olivier.nic...@cs.ait.ac.th> > > <mailto:olivier.nic...@cs.ait.ac.th > > <mailto:olivier.nic...@cs.ait.ac.th>>>: > > > > > > Hi, > > > > > > > I'm building a simple pair of front MX-servers to get rid of > our > > > cisco ironports. For spam and > > > > virus-scanning i'd like to have spamassassin and clamav doing > > > pre-filtering during smtp-dialog > > > > rejecting bad mails and forwarding good mails to internal > > mail-farm. > > > > > > While for virus you may argue that there is a clear cut > > between clean > > > and infected message, it is far from being as clear for spam. > > What you > > > consider spam and would reject may be completly valid for > > another user. > > > > > > So, rejecting spam during smtp-dialog is risky, that is why > > most resolve > > > to some sort of quarantine, and that is when amavis comes > handy. > > > > > > Best regards, > > > > > > Olivier > > > > > >
Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?
Is there documentation available, at which smtp-state a milter is kicking in? I don't see a way to define at which state a milter should take action. i would lke to make sure that smtpd_milters = unix:/clamav/clamav-milter.ctl will only get triggered *after * smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, is checked. amavis-milter seems dead. Am Fr., 19. Okt. 2018 um 08:33 Uhr schrieb Carsten Rosenberg : > Hi, > > smtp_milters and restrictions are working at the same time. > smtpd_recipient_restriction will be evaluated at the same as the Milter > RCPT stage. > > So a ClamAV Milter should run at EOM milter stage. Anything else is > useless ;) > > And in my opinion quarantine is sooo 2010. Reject (pre-queue) or > deliver, so it's clear for sender and recipient. > > Have a look to amavis-milter (+spamassassin+clamav) or even rspamd. > > > Carsten > > On 19.10.18 07:15, Stefan Bauer wrote: > > Thank you for your feedback. Seems like smtpd_milters are also used > > before any other check_*_access and rbl checks/header checks etc., so > > it's expensive this way, to pipe every mail through virus scan. > > I'm just testing if i could plug in clamav by check_policy_service. > > > > Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier > > mailto:olivier.nic...@cs.ait.ac.th>>: > > > > Hi, > > > > > I'm building a simple pair of front MX-servers to get rid of our > > cisco ironports. For spam and > > > virus-scanning i'd like to have spamassassin and clamav doing > > pre-filtering during smtp-dialog > > > rejecting bad mails and forwarding good mails to internal > mail-farm. > > > > While for virus you may argue that there is a clear cut between clean > > and infected message, it is far from being as clear for spam. What > you > > consider spam and would reject may be completly valid for another > user. > > > > So, rejecting spam during smtp-dialog is risky, that is why most > resolve > > to some sort of quarantine, and that is when amavis comes handy. > > > > Best regards, > > > > Olivier > > >
Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?
Thank you for your feedback. Seems like smtpd_milters are also used before any other check_*_access and rbl checks/header checks etc., so it's expensive this way, to pipe every mail through virus scan. I'm just testing if i could plug in clamav by check_policy_service. Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier < olivier.nic...@cs.ait.ac.th>: > Hi, > > > I'm building a simple pair of front MX-servers to get rid of our cisco > ironports. For spam and > > virus-scanning i'd like to have spamassassin and clamav doing > pre-filtering during smtp-dialog > > rejecting bad mails and forwarding good mails to internal mail-farm. > > While for virus you may argue that there is a clear cut between clean > and infected message, it is far from being as clear for spam. What you > consider spam and would reject may be completly valid for another user. > > So, rejecting spam during smtp-dialog is risky, that is why most resolve > to some sort of quarantine, and that is when amavis comes handy. > > Best regards, > > Olivier >
best practice - integrating spamassassin/clamav in postfix - amavis yes/no?
Dear Users, I'm building a simple pair of front MX-servers to get rid of our cisco ironports. For spam and virus-scanning i'd like to have spamassassin and clamav doing pre-filtering during smtp-dialog rejecting bad mails and forwarding good mails to internal mail-farm. Is it best practice to use amavis in between postfix and clamd/spamasassin? i would like to keep the setup as simple as possible and not having another component in place (amavis) when this can be avoided. I see the internet is full of setups with amavis but i dont see the reason for having another software running. What is your opinion? thank you. Stefan
Re: making unverified_recipient_reject_code safe for temp errors
Yes, that's it. Thank you! Am Fr., 12. Okt. 2018 um 14:27 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > That's the probe's 421 result: > > > Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: > to=, > > relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0, > > status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: > 421 > > internal error: OpenResolveAddrFolder failed) > > > NOQUEUE: reject: RCPT from jir01.int.domain.tld[ip2]: 450 4.1.1 > > : Recipient address rejected: unverified address: > > host 127.0.0.1[127.0.0.1] refused to talk to me: 421 internal error: > > GetSession failed; from= to= > > proto=ESMTP helo= > > And that's the Postfix 450 SMTP server response. > > Is that clear now? > > Wietse >
Re: making unverified_recipient_reject_code safe for temp errors
But what was postfix reporting to the Appliance that tried to deliver to postfix? The 421 is what postfix got from the groupware. Not what it was reporting to the deliverer. Our setup is appliance -> Postfix -> Groupware. The appliance bounced several mails with a 550 5.1.0 Address rejected. Am Do., 11. Okt. 2018 um 22:12 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > We just noticed, that senders got several "550 5.1.0 Address rejected" > > bounces even though postfix logs no permanent errors. > > > > Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: > to=, > > relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0, > > status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: > 421 > > internal error: OpenResolveAddrFolder failed) > > > > Isn't status=undeliverable a 5xx reject? > > The '421' is what really matters here. > > Wietse >
Re: making unverified_recipient_reject_code safe for temp errors
We just noticed, that senders got several "550 5.1.0 Address rejected" bounces even though postfix logs no permanent errors. Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: to=, relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0, status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: 421 internal error: OpenResolveAddrFolder failed) Isn't status=undeliverable a 5xx reject? Am Do., 11. Okt. 2018 um 19:14 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Dear Users, > > > > we have the following in place: > > > > smtpd_recipient_restrictions = reject_unknown_recipient_domain, > > reject_unverified_recipient > > unverified_recipient_reject_code = 550 > > unknown_address_reject_code = 550 > > > > today, we had an issue with our groupware so the following was happening: > > > > NOQUEUE: reject: RCPT from unknown[ip]: 450 4.1.1 : > > Recipient address rejected: unverified address: Address verification in > > progress; from= to= > > proto=ESMTP helo= > > Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: > to=, > > relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0, > > status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: > 421 > > internal error: OpenResolveAddrFolder failed) > > NOQUEUE: reject: RCPT from jir01.int.domain.tld[ip2]: 450 4.1.1 > > : Recipient address rejected: unverified address: > > host 127.0.0.1[127.0.0.1] refused to talk to me: 421 internal error: > > GetSession failed; from= to= > > proto=ESMTP helo= > > > > How do we reject unknown destinations / recipients still with a perm. > > error, but be more robust against temp errors like the ones above? > > As a matter of principle, I would consider it a bug if Postfix did > a 5XX reject after Postfix received a 4XX error. It's basic error > propagation hygiene. > > Wietse > > Wietse >
Re: Authenticating 'From' header to match envelope
Johannes,
did you double check if your planned setup will not break other things?
Have similar needs but am not yet deep enough into mail to see possible
pitfalls.
Stefan
Am Dienstag, 2. Oktober 2018 schrieb Johannes Bauer :
> Hi list,
>
> I'm having an issue with my Postfix configuration: Currently I've it set
> up so that one authentication SASL login (e.g., m...@foo.com) supports
> multiple virtual email addresses (e.g., m...@foo.com but also
> f...@foo.com, b...@foo.com).
>
> Once authenticated with m...@foo.com, the envelope sender ("MAIL FROM")
> is restricted to only the permissible variants.
>
> However, as I've now painfully found out, when in Thunderbird someone
> uses the "Custom From Address" feature, it doesn't change the envelope
> sender, but only the actual "From" header field. This means, I have the
> following situation:
>
> Auth: m...@foo.com
> Envelope from: m...@foo.com
> Header 'From': anyth...@goes.com
>
> One of my customers used a gmail address in the header "From", sent an
> email to @hotmail.com and now my mailserver is permablocked at Microsoft
> for bad reputation.
>
> How can I ensure in the future that the same checks are applied to the
> Header "From" field that are also applied to the evelope "From" field?
>
> Thanks,
> Johannes
>
check if envelope from and from is the same
Hi, we're running a small smtp send only service for authenticated users only. Even though we only accept allowed combinations of authenticated user and pre-defined envelope from addresses with access_maps, some smartasses started to spoof From: addresses so we got bad reputation at receiver sites. Is this a good idea to check if envelope from and from matches and if so, howto do it in postfix? thank you Stefan
Re: empty MAIL FROM and check_sender_access
I notice that only outlook out of all my mail clients, use the null mailer address. it looks to me after reading the standard - that outlook does it right. Is that correct? Am Di., 25. Sep. 2018 um 17:22 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 25, 2018, at 10:13 AM, Stefan Bauer > wrote: > > > > I was more asking if it's even a good idea to add the null entry to the > table? i would like to be a good postmaster but not want to relax policies > for allowed sender addresses. > > You need to allow mail with null return addresses. These are required in > bounces > and auto-replies to avoid loops. > > -- > Viktor. > >
empty MAIL FROM and check_sender_access
I was more asking if it's even a good idea to add the null entry to the table? i would like to be a good postmaster but not want to relax policies for allowed sender addresses. Am Di., 25. Sep. 2018 um 13:26 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > > Stefan Bauer: > > Hi, > > > > I'm using smtpd_sender_restrictions = check_sender_access > > hash:/etc/postfix/allowed_sender > > > > to make sure, my senders only send out with pre-defined and allowed domains. > > > > Now i noticed, that if my users acknowledge "read confirmations" in > > clients, mails in the following form arrive at postfix: > > > > from=<> to= proto=ESMTP helo= > > > > and will be rejected as empty mail from is not allowed by > > check_sender_access. > > > > Howto deal with that? > > http://www.postfix.org/postconf.5.html#smtpd_null_access_lookup_key > > Wietse
empty MAIL FROM and check_sender_access
Hi, I'm using smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/allowed_sender to make sure, my senders only send out with pre-defined and allowed domains. Now i noticed, that if my users acknowledge "read confirmations" in clients, mails in the following form arrive at postfix: from=<> to= proto=ESMTP helo= and will be rejected as empty mail from is not allowed by check_sender_access. Howto deal with that?
Re: smtp_tls_security_level = encrypt and MX-serves with mixed support for encryption
thank you. this is awesome! Am Dienstag, 18. September 2018 schrieb Viktor Dukhovni : >> On Sep 18, 2018, at 5:58 AM, Stefan Bauer wrote: >> >> I noticed the following today. Is this part of the standard? > > You should have asked "is this expected behaviour in Postfix"? And the > answer is "yes". > >> For recipient domain: >> >> MX 5 mx1.recipient.com - does not support TLS and refused delivery with temp error >> MX 10 mx2.recipient.com - does support TLS and took the mail >> >> Sep 18 10:36:29 B245080E75: TLS is required, but was not offered by host mx1.recipient.com[1.2.3.4] >> Sep 18 10:36:29 Untrusted TLS connection established to >> mx2.recipient.com[5.4.3.2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >> >> smtp_delivery_status_filter was in place for above temp error, but it >> was not mapped to permanent error (which makes sense to me. > > This is because "smtp_delivery_status_filter" applies to the *final* status > of a recipient once all the applicable MX hosts have been tried: > >http://www.postfix.org/postconf.5.html#default_delivery_status_filter > >Note: the (smtp|lmtp)_delivery_status_filter is applied only once per >recipient: when delivery is successful, when delivery is rejected with >5XX, or when there are no more alternate MX or A destinations. Use >smtp_reply_filter or lmtp_reply_filter to inspect responses for all >delivery attempts. > > -- > Viktor. > >
Re: smtp_tls_security_level = encrypt and MX-serves with mixed support for encryption
my point is that i already map this error to a perm one but in this case a backup mx was avail that was tls aware and was used in a second attempt. i like the noticed behavior but asked, why it is like that. expected perm error and bounce like when no backup mx avail. Am Dienstag, 18. September 2018 schrieb Matus UHLAR - fantomas : > On 18.09.18 14:43, Stefan Bauer wrote: >> >> I was expecting that the mail would bounce as the first MX refuses to talk >> TLS and i mapped that to a perm error. But postfix skips the one with >> temporary/temp error and delivered to the second that offered TLS. > > I think your logic is flawed. the SSL handshake can fail because of many > (temporary) reasons. If you just want to generate problems, you can try to > make that error permanent. > > But the fact that secondary MX does allow TLS should mean that you were able > to pass the message to recipient server via TLS, so what's the point of > generating permanent error in this case? This is exactly what backup MX > servers are for... > >> Am Di., 18. Sep. 2018 um 14:36 Uhr schrieb Wietse Venema < >> wie...@porcupine.org>: >> >>> Stefan Bauer: >>> > Hi, >>> > >>> > i noticed the following today. Is this part of the standard? >>> >>> There is no standard that requires TLS for MTA-to-MTA deliveries. >>> >>> > For recipient domain: >>> > >>> > MX 5 mx1.recipient.com - does not support TLS and refused delivery with >>> > temp error >>> > MX 10 mx2.recipient.com - does support TLS and took the mail >>> > >>> > Sep 18 10:36:29 B245080E75: TLS is required, but was not offered by host >>> > mx1.recipient.com[1.2.3.4] >>> > Sep 18 10:36:29 Untrusted TLS connection established to >>> > mx2.recipient.com[5.4.3.2]:25: >>> > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) >>> > >>> > smtp_delivery_status_filter was in place for above temp error, but it was >>> > not mapped to permanent error (which makes sense to me. >>> >>> What is the problem? > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease >
Re: smtp_tls_security_level = encrypt and MX-serves with mixed support for encryption
I was expecting that the mail would bounce as the first MX refuses to talk TLS and i mapped that to a perm error. But postfix skips the one with temporary/temp error and delivered to the second that offered TLS. Am Di., 18. Sep. 2018 um 14:36 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Hi, > > > > i noticed the following today. Is this part of the standard? > > There is no standard that requires TLS for MTA-to-MTA deliveries. > > > For recipient domain: > > > > MX 5 mx1.recipient.com - does not support TLS and refused delivery with > > temp error > > MX 10 mx2.recipient.com - does support TLS and took the mail > > > > Sep 18 10:36:29 B245080E75: TLS is required, but was not offered by host > > mx1.recipient.com[1.2.3.4] > > Sep 18 10:36:29 Untrusted TLS connection established to > > mx2.recipient.com[5.4.3.2]:25: > > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) > > > > smtp_delivery_status_filter was in place for above temp error, but it was > > not mapped to permanent error (which makes sense to me. > > What is the problem? > > Wietse >
smtp_tls_security_level = encrypt and MX-serves with mixed support for encryption
Hi, i noticed the following today. Is this part of the standard? For recipient domain: MX 5 mx1.recipient.com - does not support TLS and refused delivery with temp error MX 10 mx2.recipient.com - does support TLS and took the mail Sep 18 10:36:29 B245080E75: TLS is required, but was not offered by host mx1.recipient.com[1.2.3.4] Sep 18 10:36:29 Untrusted TLS connection established to mx2.recipient.com[5.4.3.2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) smtp_delivery_status_filter was in place for above temp error, but it was not mapped to permanent error (which makes sense to me.
Re: best practice anti virus integration & custom reject messages
Thank you! I was too stupid to RTFM. Clamd can provide custom reject
messages.
Am Mo., 17. Sep. 2018 um 16:18 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:
> Stefan Bauer:
> > Hi,
> >
> > I like the clean and easy milter way and having clamd this way integrated
> > in postfix. But i can not use custom reject message in case clamd detects
> > virus.
> >
> > postfix/cleanup[4292]: BD6BA80ACA: milter-reject: END-OF-MESSAGE from
> > (...): 5.7.1 Command rejected; from= to= proto=ESMTP
> > helo=
> >
> > This message lacks basic information - virus detected.
>
> That is because the Milter did not provide that a reason in the
> response to Postfix. The milter could be changed to provide a reason:
> see discussion below.
>
> > smtp_delivery_status_filters seems to not work in this case. Right?
>
> As documented that is applicable for SENDING, not RECEIVING email.
>
> > Pulling in amavis as well might give option to have custom reject
> > messages, but i do not like to have an additonal service in the
> > chain.
>
> Postfix has no 'milter reply filter' feature and it is unlikely to
> happen.
>
> To solve this problem you'd pass the Milter response through another
> program, or you would use a virus detector that produces more
> informative responses.
>
> The Milter replies with code SMFIR_REJECT, which supports no
> indication why mail is rejected:
>
> * SMFIR_REJECT
> In response to a RCPT command, indicates that the recipient
> should be rejected with a permanent error. In any other context
> this indicates that the entire message should be rejected with
> a permanent error and that no further milter commands or responses
> will be exchanged.
>
> The Milter could be improved by sending SMFIR_REPLYCODE instead,
> which allows the Milter to provide the complete SMTP server response
> to Postfix, including SMTP code and text.
>
> * SMFIR_REPLYCODE
> In response to a RCPT command, indicates that the recipient
> should be rejected with the specified error. In any other context
> this indicates that the entire message should be rejected with
> the specified error and that no further milter commands or
> responses will be exchanged.
>
> Below is the code that handles the Milter response.
>
> Wietse
>
> case SMFIR_REJECT:
> if (data_size != 0)
> break;
> if (IN_CONNECT_EVENT(event)) {
> #ifdef LIBMILTER_AUTO_DISCONNECT
> milter8_close_stream(milter);
> #endif
> milter->state = MILTER8_STAT_REJECT_CON;
> MILTER8_EVENT_BREAK(milter8_def_reply(milter, "550 5.7.1
> Command rejected"));
> } else {
> MILTER8_EVENT_BREAK("550 5.7.1 Command rejected");
> }
>
>
Re: reject_unverified_recipient and /ect/aliases delay/issue
5 Minutes are no problem. The default values indicate 3 hours right? *address_verify_negative_refresh_time <http://www.postfix.org/postconf.5.html#address_verify_negative_refresh_time> (3h)* The time after which a failed address verification probe needs to be refreshed. Am Fr., 14. Sep. 2018 um 20:25 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > Stefan Bauer: > > Am Freitag, 14. September 2018 schrieb Wietse Venema : > > > Stefan Bauer: > > >> verify_cache.db seems to get corrupted or at least not updated > properly > > as > > >> new/updated entries do not get correctly verified and postfix logs: > > >> > > >> close database /var/lib/postfix/verify_cache.db: No such file or > > directory > > >> > (possible Berkeley DB bug > > > > > > That is logged after 'postfix reload", and until now has not been > > > a problem. The warnming is logged just to be sure, because people > > > keep imprving Berkeley DB. > > > > > >> only a postfix stop, rm verify_cache* , postfix start helps. > > > > > > That is complete and utter overkill. > > > > so what else is recommended to update the db to have recent data? > > Perhaps use the configurable features to control caching of 'negative' > results: > > address_verify_negative_cache = yes > address_verify_negative_expire_time = 3d > address_verify_negative_refresh_time = 3h > > The 'negative' results are cached to avoid overloading the server > with address verify messages. > > I guess that some people can wait for 5 minutes until the negative > cache result has expired? > > Wietse >
best practice anti virus integration & custom reject messages
Hi, I like the clean and easy milter way and having clamd this way integrated in postfix. But i can not use custom reject message in case clamd detects virus. postfix/cleanup[4292]: BD6BA80ACA: milter-reject: END-OF-MESSAGE from (...): 5.7.1 Command rejected; from= to= proto=ESMTP helo= This message lacks basic information - virus detected. smtp_delivery_status_filters seems to not work in this case. Right? Pulling in amavis as well might give option to have custom reject messages, but i do not like to have an additonal service in the chain. Any other option available?
Re: reject_unverified_recipient and /ect/aliases delay/issue
Am Freitag, 14. September 2018 schrieb Wietse Venema : > Stefan Bauer: >> verify_cache.db seems to get corrupted or at least not updated properly as >> new/updated entries do not get correctly verified and postfix logs: >> >> close database /var/lib/postfix/verify_cache.db: No such file or directory >> > (possible Berkeley DB bug > > That is logged after 'postfix reload", and until now has not been > a problem. The warnming is logged just to be sure, because people > keep imprving Berkeley DB. > >> only a postfix stop, rm verify_cache* , postfix start helps. > > That is complete and utter overkill. so what else is recommended to update the db to have recent data?
reject_unverified_recipient and /ect/aliases delay/issue
Hi, we use reject_unverified_recipient and have alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases after changes in aliases and issuing postalias /etc/aliases verify_cache.db seems to get corrupted or at least not updated properly as new/updated entries do not get correctly verified and postfix logs: close database /var/lib/postfix/verify_cache.db: No such file or directory > (possible Berkeley DB bug only a postfix stop, rm verify_cache* , postfix start helps. are there known limitations?
Re: postfix does not bounce instantly when remote party does not offer TLS
Our quick and dirty approach is to parse output of mailq, delete mail and construct a bounce message, but that is far away from a clean solution ;/ No other way available? Am So., 9. Sep. 2018 um 19:27 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 1:01 PM, Stefan Bauer > wrote: > > > > any way to inform my users about TLS fails via bounce without waiting > queue lifetime? > > http://www.postfix.org/postconf.5.html#delay_warning_time > > In corporate systems I tend to split the mail plant into separate inbound > and outbound systems, and only enable delay warnings on the outbound side. > > -- > Viktor. > >
Re: smtp_tls_policy_maps on a per tls user basis
So each sender's instance is an own smtp-line in master.cf ? If so - does it work like this? src_domain1 unix - - n - - smtp -o smtp_tls_policy_maps = hash:/etc/postfix/tls_policy -o syslog_name=src_domain1 tls_policy: domain-that-does-not-support-tls.tld none and in main.cf sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport sender_transport: @src_domain1src_domain1: Is that correct? If so - will all settings from main.cf be used as well for additional smtp-instances? like smtp_tls_security_level encrypt ? Am So., 9. Sep. 2018 um 21:51 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 3:39 PM, Stefan Bauer > wrote: > > > > I see no way to combine both. I want to enforce tls for sender1 to > google.com but not for sender2 to google.com. > > I assume you don't literally mean "google.com", since they support > TLS, and you can just enforce TLS to "google.com" for both and be > done. > > For domains where you're less certain of ongoing TLS support, you > can try to deal with this by choosing different transports for > mail from sender1 vs. mail from sender2, via > sender_default_transport_maps. In sender1's instance of the > smtp(8) transport, the TLS policy will be mandatory for > "example.com" recipients, while in sender2'd instance of > the smtp(8) transport it will be opportunistic. > > -- > -- > Viktor. > >
Re: smtp_tls_policy_maps on a per tls user basis
Am Sonntag, 9. September 2018 schrieb Wietse Venema :
> Instead, you can use transport_maps to choose between different
> Postfix SMTP clients (with different configurations) based on the
> recipient address or domain.
>
> You can use the access map or header/body_checks FILTER action
> ("FILTER name-of-transport:", without a domain after the ":") to
> choose delivery methods based on other message properties, with
> some loss of elegance.
I see no way to combine both. I want to enforce tls for sender1 to
google.com but not for sender2 to google.com.
Re: postfix does not bounce instantly when remote party does not offer TLS
our system is only outbound but here when TLS fails so remote sites, we would be happy to have an option to instantly bounce as this is mostly a fixed state. Am So., 9. Sep. 2018 um 19:27 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 1:01 PM, Stefan Bauer > wrote: > > > > any way to inform my users about TLS fails via bounce without waiting > queue lifetime? > > http://www.postfix.org/postconf.5.html#delay_warning_time > > In corporate systems I tend to split the mail plant into separate inbound > and outbound systems, and only enable delay warnings on the outbound side. > > -- > Viktor. > >
Re: Host offered STARTTLS: [mxlb... without relation to destination domain
That would be great to have this as part of the log string! Thank you for considering my request. Am So., 9. Sep. 2018 um 19:03 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 9:46 AM, Stefan Bauer > wrote: > > > > I like the option smtp_tls_note_starttls_offer = yes > > but when a host is logged, it's hard to keep track to which recipient > > domain that host belong without doing dns-lookups against all listed > > in smtp_tls_policy_maps. > > Well, TLS is by nexthop domain not recipient domain. Typically the > nexthop domain is the recipient domain, but with "relayhost" or > other transport overrides, they need not be the same. So if your > goal is discover which policy got you there, then you want the > nexthop logged. > > If you use the collate.pl script (which may need tweaks to > match the initial boilerplate part of your syslog message format > with the data, hostname, ...) included with the Postfix source > you can see which deliveries correspond to the messages in > question. We could log the nexthop domain in a future release, > this is not an unreasonable request. > > -- > Viktor. > >
Re: postfix does not bounce instantly when remote party does not offer TLS
seems to only work when postfix is server. I need this for postfix as client when remote site is not offering tls. Am So., 9. Sep. 2018 um 18:59 Uhr schrieb Herbert J. Skuhra < herb...@gojira.at>: > On Sun, Sep 09, 2018 at 06:49:07PM +0200, Stefan Bauer wrote: > > Hi, > > > > delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but > > was not offered by host > > > > seems to me like a permanent error - postfix sees it as a temporary one. > I > > would like to have instant bounce message for this case when TLS is not > > available. > > > > sending postfix is configured 'encrypted' os no fallback is wanted. > > http://www.postfix.org/postconf.5.html#plaintext_reject_code > > ? > > -- > Herbert >
Re: postfix does not bounce instantly when remote party does not offer TLS
any way to inform my users about TLS fails via bounce without waiting queue lifetime? Am So., 9. Sep. 2018 um 18:58 Uhr schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: > > > > On Sep 9, 2018, at 12:49 PM, Stefan Bauer > wrote: > > > > delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but > was not offered by host > > > > seems to me like a permanent error - postfix sees it as a temporary one. > I would like to have instant bounce message for this case when TLS is not > available. > > This type of error is often fixed within the queue lifetime of a message. > If TLS was working for a destination, and was misconfigured down, the > miscreant administrator should notice and bring it back. > > If you're requiring TLS support from strangers who might never have > offered TLS, and expect delivery or an immediate bounce, we don't > yet support that. > > -- > Viktor. > >
postfix does not bounce instantly when remote party does not offer TLS
Hi, delays=422/0.03/0.09/0, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host seems to me like a permanent error - postfix sees it as a temporary one. I would like to have instant bounce message for this case when TLS is not available. sending postfix is configured 'encrypted' os no fallback is wanted.
Re: smtp_tls_policy_maps on a per tls user basis
Thank you. Before diving deeper into this, you're saying it is possible
with postfix to setup a static routing (with maps / tables) in the form:
mails from Domain-A or specific SASL-user to DOMAIN Z with enforced TLS
mails from Domain-B or specific SASL-user to DOMAIN Z with none TLS
Is that correct?
Am So., 9. Sep. 2018 um 16:28 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:
> Stefan Bauer:
> > Hi,
> >
> > is there a way to specify on a per user basis (sasl authenticated user)
> if
> > TLS should be none or may or encrypted for a specific recipient domain?
>
> There is no "per-recipient map" version for Postfix SMTP client
> parameters (or most other parameters). It does not make sense,
> because
> - One message may have multiple recipients.
> - One connection may deliver multiple messages.
> - TLS is a connection property, not a recipient property.
>
> Instead, you can use transport_maps to choose between different
> Postfix SMTP clients (with different configurations) based on the
> recipient address or domain.
>
> You can use the access map or header/body_checks FILTER action
> ("FILTER name-of-transport:", without a domain after the ":") to
> choose delivery methods based on other message properties, with
> some loss of elegance.
>
> > I would like to have the user to decide if his mail to a specific domain
> > should be TLS encrypted and then maybe bounce back but let other users
> > mails to same destination domain go ahead with a may or none.
>
> That should be possible: use the transport_maps to choose between
> one Postfix SMTP client that requires TLS, and one Postfix SMTP
> client that does not. This should even work when an encrypted
> connection is reused (smtp_tls_connection_reuse = yes).
>
> Wietse
>
