Re: RESTRICTION_CLASS_README
On Fri, Jul 09, 2021 at 07:54:54PM -0400, post...@ptld.com wrote: > > On 07-09-2021 7:44 pm, Viktor Dukhovni wrote: > > > > You don't need restriction classes for these specific cases, > > they can be used directly: > > > > /etc/postfix/recipient_access: > > joe@my.domain permit > > jane@my.domain reject_unknown_sender_domain, > > reject_unknown_client_hostname, > > reject_unknown_helo_hostname > > Thank you, i think that will work. I assume i can return that from an > sql query as a single string like > > SELECT restrictions FROM rules WHERE email=%s > > And in sql the restrictions column can store > "reject_unknown_sender_domain,reject_unknown_client_hostname" You can store them comma-separated in a single column, or as multiple rows, from which you extract a column. The Postfix (My|Pg)SQL driver will then automatically join the results with a ",". If you want predictable ordering, you may need to also have a priority column, the PgSQL syntax would be: SELECT r FROM ( SELECT restriction, priority FROM restrictions WHERE email = '%s' ORDER BY priority ) AS T(r, p); -- Viktor.
check_recipient_access
What does "resolved RCPT TO address" mean? If the mail was sent to an alias does postfix send the alias or the address the alias points to, to the table?
Manual Typo - ADDRESS_VERIFICATION_README
http://www.postfix.org/ADDRESS_VERIFICATION_README.html "The downside of using a non-empty sender address is that the address may end op on spammer mailing lists." op = up?
Re: Can send but not receive
Hey Keith On Fri, 9 Jul 2021, techli...@phpcoderusa.com wrote: I removed the vhost for keiththewebguy.com off my VPS and now I can send from the VPS to my home server. Is this normal behavior? I've always found it amusingly odd when people refer to "my internet" and I suppose "my VPS" hits me the same way. I suspect that whomever provides your VPS is trying to hit a sweet spot of turnkey features with a minimum of support interventions. So, the mix of features probably depends on the mix of customers. There is a fabric of services which must interoperate, including DNS, mail, web in almost all cases and then whatever they care to add to differentiate themselves. Central rule of networks after #0: "the network is not reliable"... is "my network my rules" and if stuff originates with their VPS then it originates under their rules. -- Fred Morris m3...@m3047.net
Re: RESTRICTION_CLASS_README
On 07-09-2021 7:50 pm, Paolo Schiro wrote: I'm pretty shure you can group restrictions in classes for example: restrictive2 = reject_unknown_sender_domain,reject_unknown_client_hostname But I'm not shure they will be all applicable in the rcpt to stage. Yes, you can group multiple restrictions per class as that is their purpose. The example in the manual gives a grouping example. However i was looking for a solution that isn't grouped because not each user would want all of the same restrictions in a group. Victor put me on the right path to do that.
Re: RESTRICTION_CLASS_README
On 07-09-2021 7:44 pm, Viktor Dukhovni wrote: You don't need restriction classes for these specific cases, they can be used directly: /etc/postfix/recipient_access: joe@my.domain permit jane@my.domain reject_unknown_sender_domain, reject_unknown_client_hostname, reject_unknown_helo_hostname Thank you, i think that will work. I assume i can return that from an sql query as a single string like SELECT restrictions FROM rules WHERE email=%s And in sql the restrictions column can store "reject_unknown_sender_domain,reject_unknown_client_hostname"
Re: RESTRICTION_CLASS_README
I'm pretty shure you can group restrictions in classes for example: restrictive2 = reject_unknown_sender_domain,reject_unknown_client_hostname But I'm not shure they will be all applicable in the rcpt to stage. Messaggio Originale Da: post...@ptld.com Inviato: Sat Jul 10 01:34:36 GMT+02:00 2021 A: postfix-users@postfix.org Oggetto: RESTRICTION_CLASS_README End goal is to have different smtpd_*_restrictions per recipient. I see restriction classes might solve this. Can you supply more than one class in the access table? smtpd_restriction_classes = permissive, restrictive1, restrictive2, restrictive3 permissive = permit restrictive1 = reject_unknown_sender_domain restrictive2 = reject_unknown_client_hostname restrictive3 = reject_unknown_helo_hostname smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_access /etc/postfix/recipient_access: joe@my.domain permissive jane@my.domain restrictive1 restrictive2 restrictive3 I would do this with sql instead of a flat file table and assume it would translate over the same. If this isn't the answer is there another way to go about this?
Re: RESTRICTION_CLASS_README
On Fri, Jul 09, 2021 at 07:34:36PM -0400, post...@ptld.com wrote: > End goal is to have different smtpd_*_restrictions per recipient. > I see restriction classes might solve this. > Can you supply more than one class in the access table? > > smtpd_restriction_classes = permissive, restrictive1, restrictive2, > restrictive3 > permissive = permit > restrictive1 = reject_unknown_sender_domain > restrictive2 = reject_unknown_client_hostname > restrictive3 = reject_unknown_helo_hostname You don't need restriction classes for these specific cases, they can be used directly: /etc/postfix/recipient_access: joe@my.domain permit jane@my.domain reject_unknown_sender_domain, reject_unknown_client_hostname, reject_unknown_helo_hostname Restriction classes are needed once restrictions make use of external lookup tables, policy services, ... that require open connections prior to restriction evaluation. You can of course use them as aliases for lists of the simple built-in primitives above, but this is not required. > smtpd_recipient_restrictions = > check_recipient_access hash:/etc/postfix/recipient_access > > /etc/postfix/recipient_access: > joe@my.domain permissive > jane@my.domain restrictive1 restrictive2 restrictive3 Yes, you can use a list of built-in non-table primitives and/or restriction classes. -- Viiktor.
Re: Can send but not receive
> I had not removed the vhost on the VPS for keiththewebguy.com, so when I sent > email from the VPS to my home server, it saw the same email on the local > server (VPS) and routed it to the inbox. > > I am very surprised this occurred. I would have thought the sending server > (VPS) would follow the DNS to my home server. > > I removed the vhost for keiththewebguy.com off my VPS and now I can send from > the VPS to my home server. > > Is this normal behavior? Yes, it is. Usually configuration takes precedence over DNS. Imagine your company's MX is accepting mail but does not store it. Instead it is forwarded to another mailserver within your local network, e.g. for security reasons. That internal server is not listed in DNS and accepts mail only because it is configured to do so. Best regards, Gerald
RESTRICTION_CLASS_README
End goal is to have different smtpd_*_restrictions per recipient. I see restriction classes might solve this. Can you supply more than one class in the access table? smtpd_restriction_classes = permissive, restrictive1, restrictive2, restrictive3 permissive = permit restrictive1 = reject_unknown_sender_domain restrictive2 = reject_unknown_client_hostname restrictive3 = reject_unknown_helo_hostname smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_access /etc/postfix/recipient_access: joe@my.domain permissive jane@my.domain restrictive1 restrictive2 restrictive3 I would do this with sql instead of a flat file table and assume it would translate over the same. If this isn't the answer is there another way to go about this?
Re: Licensing question
>From: owner-postfix-us...@postfix.org > >Paolo Schiro: >> Hallo everybody, >> >> I've wrote a postfix toolkit to report and act on the queue in a sharp way. >> I would like to release it under GPL or some other free license. >> To handle queue efficently i rewrote the rec_get sub in perl (I discovered >> it was already present in qshape too late) >> In my understanding about the IBM Public License Version 1 I need to release >> the toolkit under IBM license or at least place the sub in a specific file >> and distribute it under IBM license and the rest in any license i wish. >> >> Can anyone confirm I understood correctly ? > >If you re-implement rec_get() under GPL then no-one will come after you. More than re-implemented I've "translated" from an older version of record.c I don't think change licensing is applicable anyway. >On the other hand, if you read or write Postfix queue files, then >your program is not supported, that is, it will break when changes >are made to the queue file details. I always provide backwards >compatibiliity for Postfix programs, but never for other programs. One more reason to replace my read function with rec_get() from qshape.pl, mantaining future version will be easier for me. Seems to be more convenient for this project copy the function and inherit IBMPL Thanks your Paolo
Re: Can send but not receive
Thanks!! On 2021-07-08 12:11, PGNet Dev wrote: On 7/8/21 1:59 PM, techli...@phpcoderusa.com wrote: Any thought how I can troubleshoot this? map out your traffic one step at a time. connect with openssl s_client curl from an external server, and manually exec an smtp transaction. &/or, less convenietly, (re)send mail from an external mail account, gmail or somesuch. exec tcpdump on each of your listening interfaces/ports, and turn on verbose logging on all your server listeners (named, postfix & dovecot), and identify where the traffic flows to, and where it stops.
Re: Can send but not receive
Thanks!! On 2021-07-08 11:14, Gerald Galster wrote: I am running Ubuntu 20.04lts / Apache / MySql (or a clone) / PHP / BIND9 / Postfix / Dovecot Web server works. I have configred a lot of LAMP virtual host servers. I am new to BIND9 / Postfix / Dovecot. FQDN is soho.keiththewebguy.com MX record is : keiththewebguy.com. IN MX 10 soho.keiththewebguy.com. A Record : soho.keiththewebguy.com.IN A98.191.108.149 Reverse (PTR) record: 149.108.191.98.in-addr.arpa -> soho.keiththewebguy.com https://intodns.com/keiththewebguy.com says things are configured correctly. I have a Let's Encrypt wild card SSL which I placed in Postfix and Dovecot. Nothing that looks like an error in : /var/log/mail.log or /var/log/syslog I can send email however I cannot recieve. Any thought how I can troubleshoot this? Thanks!! Your mailserver is reachable (tested via mxtoolbox.com): Connecting to 98.191.108.149 220 soho.keiththewebguy.com ESMTP Postfix [220 ms] EHLO keeper-us-east-1b.mxtoolbox.com 250-soho.keiththewebguy.com 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 CHUNKING [184 ms] MAIL FROM: 250 2.1.0 Ok [185 ms] RCPT TO: 554 5.7.1 : Relay access denied [186 ms] You should find an error message in /var/log/mail.log accordingly. (Or search all logs/journalctl for mxtoolbox to locate the log) If you cannot receive mail it either has been rejected: look for 3-digit error codes starting with 5.. (= permanently rejected). or if you see 4.. -> these are temporary errors (will be retried) or if you see 2.. -> mails have been accepted; the log tells you where it has been delivered (relay= or delivered to mailbox). Best regards Gerald
Re: Can send but not receive
Hi, Problem resolved. I am very surprised at what was causing the problem. I have a VPS and it was serving keiththewebguy.com. I decided I wanted to learn BIND / Let's Encrypt / Postfix / Dovecot. I changed the host/glue records for keiththewebguy.com pointing then to my home server. I then started to configure an old laptop as a LAMP server. Then I added BIND... all was well. Then I added the free SSL ... again all was well. Then I added Postfix and Dovecot. I then circled back and fixed a couple things. I was able to send email to a domain hosted on my VPS, however I was not able to send from the VPS to keiththewebguy.com. My home server email worked with gmail and yahoo mail. Got my ISP involved and I learned the unexpected. I had not removed the vhost on the VPS for keiththewebguy.com, so when I sent email from the VPS to my home server, it saw the same email on the local server (VPS) and routed it to the inbox. I am very surprised this occurred. I would have thought the sending server (VPS) would follow the DNS to my home server. I removed the vhost for keiththewebguy.com off my VPS and now I can send from the VPS to my home server. Is this normal behavior? Thanks!! On 2021-07-08 10:59, techli...@phpcoderusa.com wrote: Hi, I am running Ubuntu 20.04lts / Apache / MySql (or a clone) / PHP / BIND9 / Postfix / Dovecot Web server works. I have configred a lot of LAMP virtual host servers. I am new to BIND9 / Postfix / Dovecot. FQDN is soho.keiththewebguy.com MX record is : keiththewebguy.com. IN MX 10 soho.keiththewebguy.com. A Record : soho.keiththewebguy.com.IN A98.191.108.149 Reverse (PTR) record: 149.108.191.98.in-addr.arpa -> soho.keiththewebguy.com https://intodns.com/keiththewebguy.com says things are configured correctly. I have a Let's Encrypt wild card SSL which I placed in Postfix and Dovecot. Nothing that looks like an error in : /var/log/mail.log or /var/log/syslog I can send email however I cannot recieve. Any thought how I can troubleshoot this? Thanks!!
Re: Licensing question
Paolo Schiro: > Hallo everybody, > > I've wrote a postfix? toolkit to report and act on the queue in a sharp way. > I would like to release it under GPL or some other free license. > To handle queue efficently i rewrote the rec_get sub in perl (I discovered it > was already present in qshape too late) > In my understanding about the IBM Public License Version 1 I need to release > the toolkit under IBM license or at least place the sub in a specific file > and distribute it under IBM license and the rest in any license i wish. > > Can anyone confirm I understood correctly ? If you re-implement rec_get() under GPL then no-one will come after you. On the other hand, if you read or write Postfix queue files, then your program is not supported, that is, it will break when changes are made to the queue file details. I always provide backwards compatibiliity for Postfix programs, but never for other programs. Wietse
Licensing question
Hallo everybody, I've wrote a postfix toolkit to report and act on the queue in a sharp way. I would like to release it under GPL or some other free license. To handle queue efficently i rewrote the rec_get sub in perl (I discovered it was already present in qshape too late) In my understanding about the IBM Public License Version 1 I need to release the toolkit under IBM license or at least place the sub in a specific file and distribute it under IBM license and the rest in any license i wish. Can anyone confirm I understood correctly ? Thanks in advance
Re: SMTP Auth bind password management
On Fri, Jul 09, 2021 at 04:13:43PM +, Wakefield, Robin wrote: > My company requires that the passwords for all technical accounts be > recycled regularly. It seems that by "technical accounts" you mean service accounts used by software subsystems rather than human users. > Our implementation of SMTP authentication uses the nslcd service - we > regularly rotate between 2 binddn accounts, so that we can perform the > password updates on the inactive account, and then replace the active > account in the conf file, etc. This sounds like accounts used to query LDAP, ... perhaps as part of authenticating remote SMTP clients. > A new requirement is to now integrate this into the HashiCorp/EVA > password management system. At present, this is being engineered > using scripts to extract the password from the HashiCorp vault, and > then update the nslcd.conf file automatically. If you have a password vault, and tools to query that vault, then it typically makes sense to automate the configuration updates. > * Are there any plans to fully integrate SMTP Authentication with > this password management system such that the mail operations team > don't even know what the password is? This does not make much sense. SMTP authentication leverages SASL which supports a number of standardised "mechanisms". Each mechanism is supported by an appropriate driver in the SASL library. Cyrus SASL has plugins, Dovecot also has various ways to validate user passwords. If validation of user passwords requires a service account password to access the relevant resources, that's all internal details in the SASL module, and not related to "SMTP authentication" as such. If you're looking for SASL plugins that integrated with HashiCorp, ask Hashicorp. One way for support teams to not need to configure passwords is to use GSSAPI authentication, with keys in keytabs or automatically provisioned and kept fresh Kerberos tickets. If the relevant backend service support GSSAPI authentication. Credential management does not go away, but you can avoid having support staff working with plaintext passwords. -- Viktor.
Re: SMTP Auth bind password management
>Wakefield, Robin: > Hello, > > My company requires that the passwords for all technical accounts > be recycled regularly. > > Our implementation of SMTP authentication uses the nslcd service > - we regularly rotate between 2 binddn accounts, so that we can > perform the password updates on the inactive account, and then > replace the active account in the conf file, etc. > > A new requirement is to now integrate this into the HashiCorp/EVA > password management system. At present, this is being engineered > using scripts to extract the password from the HashiCorp vault, > and then update the nslcd.conf file automatically. > > The question has been asked: > > * Are there any plans to fully integrate SMTP Authentication > with this password management system such that the mail operations > team don't even know what the password is? > > Has anyone any experience of this, or can suggest a way of achieving > this? If this is for receiving email, then the passwords are looked up by Cyrus SASL or Dovecot. The Postfix SMTP server does not look up passwords. If this is for sending email, then the Postfix SMTP client looks up passwords specified with smtp_sasl_password_maps. This can be a local file, a database (LDAP, SQL) client, or a client for a service that speaks the socketmap_table or tcp_table protocol. Wietse
SMTP Auth bind password management
Hello, My company requires that the passwords for all technical accounts be recycled regularly. Our implementation of SMTP authentication uses the nslcd service - we regularly rotate between 2 binddn accounts, so that we can perform the password updates on the inactive account, and then replace the active account in the conf file, etc. A new requirement is to now integrate this into the HashiCorp/EVA password management system. At present, this is being engineered using scripts to extract the password from the HashiCorp vault, and then update the nslcd.conf file automatically. The question has been asked: * Are there any plans to fully integrate SMTP Authentication with this password management system such that the mail operations team don't even know what the password is? Has anyone any experience of this, or can suggest a way of achieving this? Regards Robin W. Les informations contenues dans ce message ainsi que les pièces jointes sont exclusivement destinées aux personnes désignées en qualité de destinataires ou autorisées à les recevoir. Ces informations sont strictement confidentielles et peuvent être couvertes par le secret professionnel. Si vous avez reçu ce message par erreur, merci de le détruire ainsi que toutes les éventuelles copies et d'en informer immédiatement l'expéditeur. Nous vous rappelons qu'il est formellement interdit de le copier, le faire suivre, le divulguer ou d'en utiliser tout ou partie sous peine de poursuites civiles ou pénales. UBS (France) S.A. décline toute responsabilité quant aux erreurs ou omissions qui pourraient affecter le contenu de ce message. Vous nous avez autorisés, en nous communiquant votre adresse électronique, à vous contacter par ce moyen. Si vous ne souhaitez plus recevoir d'e-mails de notre part, veuillez l'indiquer à l'adresse suivante : communication-fra...@ubs.com. Pour savoir comment UBS traite et préserve la confidentialité de vos données à caractère personnel, consultez notre déclaration de confidentialité. https://www.ubs.com/global/fr/legal/country/france/data-privacy-notice-eugdpr.html Afin de contribuer au respect de l'environnement, merci de n'imprimer cet e-mail qu'en cas de nécessité. The information contained in this communication as well as its attachments are intended solely for the use of the individual or entity to whom it is addressed and to others authorized to receive it. It may contain confidential and privileged information. If you are not the intended recipient or if you have received this communication by error, please delete all copies from your system and notify the sender immediately by responding to this email. You are hereby notified that any disclosure, copying, distribution or taking of any action regarding the content of the information is strictly prohibited and may qualify as a criminal offence. UBS (France) S.A. declines any liability as to the errors or omissions which could affect the content of this communication. By communicating your e-mail address, you have authorized us to contact you by such a mean. Should you refuse to receive further e-mails from our company, please let us know at the following email address: communication-fra...@ubs.com. For information on how UBS processes and keeps secure your personal data, please visit our Privacy Notice. https://www.ubs.com/global/fr/legal/country/france/data-privacy-notice-eugdpr.html Please consider the environment before printing this email or its attachments.
Re: 554 bounce message lacks detail
li...@lazygranch.com: > I rarely bounced email due to RBLs from someone I actually correspond > with. However I did bounce a message with the sender receiving this > message: > > ?Sorry, we were unable to deliver your message to the following > address. If that is all the detail that the sender gets, then no amount of Postfix tweaking is going to make a difference. > From the maillog: > Jul 7 16:35:21 example postfix/smtpd[27776]: NOQUEUE: reject: RCPT from > sonic301-25.consmr.mail.gq1.yahoo.com[98.137.64.151]: 554 5.7.1 Service > unavailable; Client host [98.137.64.151] blocked using cbl.abuseat.org; > from= to= proto=ESMTP > helo= > > Now you can use mxtoolbox to see that indeed 98.137.64.151 is blocked. > Same goes for sonic301-25.consmr.mail.gq1.yahoo.com. However the sender > doesn't know the FQDN nor the IP address their email server used. > > Is there some flag I need to set to provide more information regarding > the 554 bounce? See: http://www.postfix.org/postconf.5.html#default_rbl_reply http://www.postfix.org/postconf.5.html#rbl_reply_maps > Preferably let the person know the RBL that caused it. That information is already present in the SMTP server response: 554 5.7.1 Service unavailable; Client host [98.137.64.151] blocked using cbl.abuseat.org It is up to Yahoo to pass that on to the sender. Wietse
Re: 554 bounce message lacks detail
On Fri, 9 Jul 2021 08:38:30 +0200 Matus UHLAR - fantomas wrote: > On 08.07.21 18:48, li...@lazygranch.com wrote: > >I rarely bounced email due to RBLs from someone I actually correspond > >with. However I did bounce a message with the sender receiving this > >message: > > > >Sorry, we were unable to deliver your message to the following > >address. > > >>From the maillog: > > > >Jul 7 16:35:21 example postfix/smtpd[27776]: NOQUEUE: reject: RCPT > >from > > sonic301-25.consmr.mail.gq1.yahoo.com[98.137.64.151]: 554 5.7.1 > > Service unavailable; Client host [98.137.64.151] blocked using > > cbl.abuseat.org; from= > > to= proto=ESMTP > > helo= > > This is not a bounce, this is a rejection by your MTA, and sending > MTA is responsible for creating a bounce in this case. > > Some MTAs are very shitty regarding to bounce creation, not providing > full messages. > > >Now you can use mxtoolbox to see that indeed 98.137.64.151 is > >blocked. Same goes for sonic301-25.consmr.mail.gq1.yahoo.com. > >However the sender doesn't know the FQDN nor the IP address their > >email server used. > > > >Is there some flag I need to set to provide more information > >regarding the 554 bounce? Preferably let the person know the RBL > >that caused it. > > you can add info to reject messages by configuring e.g.: > > smtpd_reject_footer_maps=regexp:/etc/postfix/reject_footes_maps > > but nobody will guarantee that the sending MTA will put that info to a > bounce. > > However, if it helps, please report this info so we know. > > I remember M$IE used to provide own error message if the message from > server was smaller than 512B (and option "show friendly HTTP error > messages" was on), making error messages useless. > For completeness (in that I should have included this): postconf mail_version mail_version = 3.5.8 OK details here: http://www.postfix.org/smtpd.8.html: http://www.postfix.org/postconf.5.html: However no examples on how to create the regex nor can I find any on the internet. How about this: /etc/postfix/main.cf: smtpd_reject_footer = \c. For assistance, call 800-555-0101. Please provide the following information in your problem report: time ($localtime), client ($client_address) and server ($server_name). I would do something more like smtpd_reject_footer = \c. In your browser go to https://mxtoolbox.com/blacklists.aspx and enter ($server_name)
Re: 554 bounce message lacks detail
On 09.07.21 08:38, Matus UHLAR - fantomas wrote: you can add info to reject messages by configuring e.g.: smtpd_reject_footer_maps=regexp:/etc/postfix/reject_footes_maps but nobody will guarantee that the sending MTA will put that info to a bounce. However, if it helps, please report this info so we know. I'll add an example, line: /User unknown in local recipient table/ Zadana mailova adresa neexistuje. in /etc/postfix/reject_footes_maps results in SMTP message: rcpt to: 550-5.1.1 : Recipient address rejected: User unknown in local recipient table 550 5.1.1 Zadana mailova adresa neexistuje. -- 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'm not interested in your website anymore. If you need cookies, bake them yourself.
