{"id":22165127,"url":"https://github.com/pkgstore-old/linux-rpm-postfix","last_synced_at":"2026-05-01T10:32:23.740Z","repository":{"id":224038300,"uuid":"378355670","full_name":"pkgstore-old/linux-rpm-postfix","owner":"pkgstore-old","description":null,"archived":false,"fork":false,"pushed_at":"2022-03-31T09:40:14.000Z","size":16767,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-24T16:13:12.016Z","etag":null,"topics":["linux","pkgstore","postfix","rpm","rpm-package","rpm-packages","rpm-spec"],"latest_commit_sha":null,"homepage":null,"language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/pkgstore-old.png","metadata":{"files":{"readme":"README-Postfix-SASL-RedHat.txt","changelog":"CHANGELOG","contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null},"funding":null},"created_at":"2021-06-19T07:50:52.000Z","updated_at":"2022-03-30T14:45:51.000Z","dependencies_parsed_at":"2024-02-23T11:54:39.242Z","dependency_job_id":"c991616c-c541-4c70-9fd1-ced1287c2d6c","html_url":"https://github.com/pkgstore-old/linux-rpm-postfix","commit_stats":null,"previous_names":["pkgstore-old/linux-rpm-postfix"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/pkgstore-old/linux-rpm-postfix","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pkgstore-old%2Flinux-rpm-postfix","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pkgstore-old%2Flinux-rpm-postfix/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pkgstore-old%2Flinux-rpm-postfix/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pkgstore-old%2Flinux-rpm-postfix/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/pkgstore-old","download_url":"https://codeload.github.com/pkgstore-old/linux-rpm-postfix/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pkgstore-old%2Flinux-rpm-postfix/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32494270,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-30T13:12:12.517Z","status":"online","status_checked_at":"2026-05-01T02:00:05.856Z","response_time":64,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["linux","pkgstore","postfix","rpm","rpm-package","rpm-packages","rpm-spec"],"created_at":"2024-12-02T05:13:21.643Z","updated_at":"2026-05-01T10:32:23.721Z","avatar_url":"https://github.com/pkgstore-old.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"Quick Start to Authenticate with SASL and PAM:\n----------------------------------------------\n\nIf you don't need the details and are an experienced system\nadministrator you can just do this, otherwise read on.\n\n1) Edit /etc/postfix/main.cf and set this:\n\nsmtpd_sasl_auth_enable = yes\nsmtpd_sasl_security_options = noanonymous\nbroken_sasl_auth_clients = yes\n\nsmtpd_recipient_restrictions = \n  permit_sasl_authenticated,\n  permit_mynetworks,\n  reject_unauth_destination\n\n2) Turn on saslauthd:\n\n   /sbin/chkconfig --level 345 saslauthd on\n   /sbin/service saslauthd start\n\n3) Edit /etc/sysconfig/saslauthd and set this:\n\n   MECH=pam\n\n4) Restart Postfix:\n\n   /sbin/service postfix restart\n\nA crash course in using SASL with Postfix:\n------------------------------------------\n\nRed Hat's Postfix RPMs include support for both SASL and TLS.  SASL, the\nSimple Authentication and Security Layer, allows Postfix to implement RFC\n2554, which defines an extension to ESMTP, SMTP AUTH, which compliant\nESMTP clients can use to authenticate themselves to ESMTP servers.\nTypically, this is used to allow roaming users to relay mail through a\nserver safely without configuring the SMTP server to be an open relay.\nInclusion of TLS support allows Postfix to implement RFC 2487, which\ndefines an extension to ESMTP, SMTP STARTTLS, which compliant ESMTP\nclients and servers can use to encrypt the SMTP session.  This is a\nsecurity enhancement -- normally SMTP is transmitted as cleartext over the\nwire, making it vulnerable to both passive sniffing and active alteration\nvia monkey-in-the-middle attacks.  In addition, STARTTLS can also be\nused by either or both server and client to verify the identity of the\nother end, making it useful for the same sorts of purposes as SMTP AUTH.\nThe two can even be combined.  Typically, this is done by first starting\nTLS, to encrypt the SMTP session, and then issuing the SMTP AUTH command,\nto authenticate the client; this combination ensures that the username\nand password transferred as part of the SMTP AUTH are protected by the\nTLS encrypted session.\n\nSMTP AUTH is implemented using SASL, an abstraction layer which can\nauthenticate against a variety of sources.  On Red Hat, SASL can use\nthe /etc/shadow file, or it can use PAM libraries, or it can use its own\npassword database (/etc/sasldb), or it can do various more exotic things.\n\nAuthentication raises a number of security concerns for obvious\nreasons. As a consequence authentication services on Red Hat systems\nare restricted to processes running with root privileges. However for\nsecurity reasons it is also essential that a mail server such as\nPostfix run without root privileges so that mail operations cannot\ncompromise the host system. This means that Postfix cannot directly\nuse authentication services because it does not execute with root\nprivileges. The answer to this this problem is to introduce an\nintermediary process that runs with root privileges which Postfix can\ncommunicate with and will perform authentication on behalf of\nPostfix. The SASL package includes an authentication daemon called\nsaslauthd which provided this service, think of it as an\nauthentication proxy.\n\nUsing Saslauthd:\n---------------- \n\nTo use saslauthd there are several things you must assure are\nconfigured. \n\nSelecting an Authentication Method:\n-----------------------------------\n\nRecall that it is saslauthd which is authenticating, not\nPostfix. To start with you must tell Postfix to use saslauthd, in\nmain.cf edit this configuration parameter:\n\n   smtpd_sasl_auth_enable = yes\n\nIt is also recommended that you disable anonymous logins otherwise\nyou've left your system open, so also add this configuration\nparameter. \n\n   smtpd_sasl_security_options = noanonymous\n\nNow you must tell saslauthd which authentication method to use. To\ndetermine the authentication methods currently supported by saslauthd\ninvoke saslauthd with the -v parameter, it will print its version and\nits list of methods and then exit, for example:\n\n   /usr/sbin/saslauthd -v\n   saslauthd 2.1.10\n   authentication mechanisms: getpwent kerberos5 pam rimap shadow \n\nWhen saslauthd starts up it reads its configuration options from the\nfile /etc/sysconfig/saslauthd. Currently there are two parameters\nwhich can be set in this file, MECH and FLAGS. MECH is the\nauthentication mechanism and FLAGS is any command line flags you may\nwish to pass to saslauthd. To tell saslauthd to use a specific\nmechanism edit /etc/sysconfig/saslauthd and set the MECH parameter,\nfor example to use PAM it would look like this:\n\n   MECH=pam\n\nOf course you may use any of the other authentication mechanisms that\nsaslauthd reported it supports. PAM is an excellent choice as PAM\nsupports many of the same authentication methods that saslauthd does,\nbut by using PAM you will have centralized all of your authentication\nconfiguration under PAM which is one of PAM's greatest assets.\n\nHow Postfix Interacts with SASL to Name its Authentication Services:\n--------------------------------------------------------------------\n\nIt can be very helpful to understand how Postfix communicates with\nSASL to name its authentication services. Knowing this will let you\nidentify the configuration files the various components will access.\n\nWhen Postfix invokes SASL it must give SASL an application name that\nSASL will use among other things to locate a configuration file for\nthe application. The application name Postfix identifies itself as is\n\"smtpd\". SASL will append \".conf\" to the application name and look for\na config file in its library and config directories. Thus SASL will\nread Postfix's configuration from\n\n   /etc/sasl2/smtpd.conf\n\nThis file names the authentication method SASL will use for Postfix\n(actually for smtpd, other MTA's such as sendmail may use the same\nfile). Because we want to use the saslauthd authentication proxy\ndaemon the contents of this file is:\n\n   pwcheck_method: saslauthd\n\nThis tells SASL when being invoked to authentication for Postfix that\nit should use saslauthd. Saslauthd's mechanism is set in\n/etc/sysconfig/saslauthd (see below).\n\nWhen Postfix calls on SASL to authenticate it passes to SASL a service\nname. This service name is used in authentication method specific\nway. The service name Postfix passes to SASL is \"smtp\" (note this is\nnot the same as the application name which is \"smtpd\"). To understand\nthis better consider the case of using PAM authentication. When SASL,\nor in our case saslauthd, invokes PAM it passes the service name of\n\"smtp\" to PAM which means that when PAM wants to read configuration\ninformation for this client it will find it under the name of \"smtp\". \n\nTurning on the Authentication Daemon:\n-------------------------------------\n\nRed Hat security policy is not to automatically enable services\nbelonging to a package when the package is installed. The system\nadministrator must explicitly enable the service. To enable saslauthd\ndo the following:\n\n1) Tell the init process to launch saslauthd when entering various run\n   levels. Assuming you want saslauthd to run at run levels 3,4,5\n   invoke chkconfig.\n\n   /sbin/chkconfig --level 345 saslauthd on\n\n2) You will probably want to start saslauthd now without having to\n   reboot, to do this:\n\n   /sbin/service saslauthd start\n\nTrouble Shooting Authentication:\n--------------------------------\n\nThe best way to debug authentication problems is to examine log\nmessages from the authentication components. However, normally these\nlog messages are suppressed. There are two principle reasons the\nmessages are suppressed. The first is that they are typically logged\nat the DEBUG logging priority level which is the lowest priority and\nthe syslog configuration typically logs only higher priority\nmessages. The second reason is that for security reasons authentication\nlogging is considered a risk. Authentication logging has been divided\ninto two different facilities, auth and authpriv. authpriv is private\nand is typically shunted off to a different log file with higher\nprotection. You will want to be able to see both auth and authpriv\nmessages at all priorities. To do this as root edit /etc/syslog.conf\nfile, find the following line\n\nauthpriv.*\t\t\t\t\t/var/log/secure\n\nedit the line to:\n\nauthpriv.*;auth.*\t\t\t\t/var/log/secure\n\nThen restart syslogd so the syslog configuration changes will be\npicked up:\n\n       /sbin/service syslog restart\n\nNow all authentication messages at all priorities will log to\n/var/log/secure. \n\nUsing PAM to Authenticate:\n--------------------------\n\nEdit /etc/sysconfig/saslauthd and set MECH to PAM like this:\n\n   MECH=pam\n\nWhen PAM is invoked via SASL it is passed a service name of\n\"smtp\". This means that PAM will read its configuration parameters for\nPostfix from the file: /etc/pam.d/smtp. By default this file is set to\nrefer to the global system PAM authentication policy, thus by default\nyou'll get whatever PAM authentication your system is configured for\nand virtually all applications use. Configuring PAM authentication is\nbeyond the scope of this document, please refer to the PAM\ndocumentation if you which to modify PAM.\n\nTrouble Shooting PAM Authentication:\n------------------------------------\n\n1) One possible reason PAM may fail to authenticate even if the user\nis known to the system is if PAM fails to find the service\nconfiguration file in /etc/pam.d. Service configuration files are not\nrequired by PAM, if it does not find a service configuration file it\nwill default to \"other\". Since PAM does not consider the absence of a\nservice configuration file a problem it does not log anything nor does\nit return an error to the calling application. In other words it is\ncompletely silent about the fact it did not find a service\nconfiguration file. On Red Hat system the default implementation of\n\"other\" for PAM is to deny access. This means on Red Hat systems the\nabsence of a PAM service configuration file will mean PAM will\nsilently fail authentication. The PAM service configuration file for\npostfix is /etc/pam.d/smtp and is intalled by the Red Hat Postfix rpm\nand put under control of \"alternatives\" with name mta. Alternatives\nallows one to select between the sendmail and postfix MTA's and\nmanages symbolic links for files the two MTA's share. /etc/pam.d/smtp\nis one such file, if you have not selected Postfix as your prefered\nMTA the link to this file will not be present. To select Postfix as\nyour MTA do this: \"/usr/sbin/alternatives --config mta\" and follow the\nprompt to select postfix.\n\n2) Is SASL appending a realm or domain to a username? PAM\n   authentication requires a bare username and password, other\n   authentication methods require the username to be qualified with a\n   realm. Typically the username will be rewritten as user@realm\n   (e.g. user@foo.com) PAM does not understand a username with\n   \"@realm\" appended to it and will fail the authentication with the\n   message that the user is unknown. If the log files shows saslauthd\n   usernames with \"@realm\" appended to it then the\n   smtpd_sasl_local_domain configuration parameter is likely set in\n   /etc/postfix/main.cf file, make sure its either not set or set it\n   to an empty string. Restart postfix and test authtentication again,\n   the log file should show only a bare username.\n\n\n\nUsing saslpasswd to Authenticate:\n---------------------------------\n\nSASL can maintain its own password database independent of the host\nsystem's authentication setup, it is called saslpasswd. You may wish\nto use saslpasswd if you want to isolate who can smtp authenticate\nfrom general system users. However, it does add another password\ndatabase that a system administrator must maintain.\n\nTo authenticate against sasldb, you'll first have to create accounts.\nThese accounts are entirely separate from system accounts, and are used\nonly by connecting SMTP clients to authenticate themselves.  Use the\nsaslpassword command:\n\nsaslpasswd -u `postconf -h myhostname` -c user\n\nto create an account named user which can log into realm.  For the\nrealm, make absolutely certain that you use the same value as is set for\nmyhostname in /etc/postfix/main.cf.  If you don't, it likely won't work.\n\nAlso, be aware that saslpasswd is somewhat buggy.  The first time you\nrun it, it may generate an error message while initializing the sasldb.\nIf it does, just add that user a second time.\n\nYou'll need to set permissions on the SASL password database so that\nthe Postfix daemons can read it:\n\n   chgrp postfix /etc/sasldb\n   chmod g+r /etc/sasldb\n\nNow, you'll need to modify /etc/postfix/main.cf to tell it to\nsupport SASL.  The complete options you might want to use are in the\nsample-auth.cf file in the Postfix documentation directory.  An option\nyou will definitely need is:\n\n# enable SASL support\nsmtpd_sasl_auth_enable = yes\n\nYou might also need to set the SASL authentication realm to whatever\nrealm you used when you created your sasldb; by default, this is set to\n$myhostname, but you instead might need something like:\n\n# set SASL realm to domain instead\nsmtpd_sasl_local_domain = $mydomain\n\nOther Postfix Authentication Parameters:\n----------------------------------------\n\nIf you want to allow your already configured users to still use your SMTP\nserver, and to allow users authenticated via SMTP AUTH to use your server\nas well, then modify your existing smtpd_recipient_restrictions line to;\n\n# also allow authenticated (RFC 2554) users\nsmtpd_recipient_restrictions = permit_sasl_authenticated ...\n\nIf you want to restrict use of your server to just authenticated clients\n(Note: this is a bad idea for public mail servers), then instead use:\n\n# restrict server access to authenticated (RFC 2554) clients\nsmtpd_delay_reject = yes\nsmtpd_client_restrictions = permit_sasl_authenticated ...\n\nSASL supports several password types which have differing security\nproperties.  Different SMTP clients may support some or all of these\npassword types.  When the client issues an EHLO command, the server\ntells it which types it supports:\n\n$ telnet station6 25\nTrying 10.100.0.6...\nConnected to station6.example.com.\nEscape character is '^]'.\n220 station6.example.com ESMTP Postfix\nehlo station7\n250-station6.example.com\n250-PIPELINING\n250-SIZE 10240000\n250-VRFY\n250-ETRN\n250-STARTTLS\n250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5\n250-XVERP\n250 8BITMIME\n\nHere, the server supports PLAIN, LOGIN, DIGEST-MD5, and CRAM-MD5 password\nmethods.\n\nThe client then chooses the first of these listed methods which it also\nsupports, and issues an SMTP AUTH request.\n\nFor security, PLAIN and LOGIN methods are typically disabled.  These two\nmethods use trivially decryptable encryption, making the username and\npassword issued by the client vulnerable to interception via a sniffer\nin between the server and client.  Unfortunately, they can't always\nbe disabled.  Some popular SMTP clients, including MS Outlook 5.x,\nonly support PLAIN authentication, for example.\n\nTo limit the login methods offered by the server:\n\n# disable unsafe password methods\nsmtpd_sasl_security_options = noplaintext noanonymous\n\nAvailable options are:\n\nnoplaintext, which disables LOGIN and PLAIN\nnoanonymous, which disables disables ANON\nnodictionary, which disables methods vulnerable to dictionary attacks\nnoactive, which disables methods vulnerable to active attacks\n\nThe last two are rarely used, since almost all supported methods are\nvulnerable to those attacks ;-).\n\nAlso be aware that some broken clients mis-implement the SMTP AUTH\nprotocol, and send commands using incorrect syntax (AUTH=foo instead of\nthe correct AUTH foo).  MS Outlook 4.x clients have this bug, among\na legion of others....  If you need to support these clients, use:\n\n# support braindead MS products\nbroken_sasl_auth_clients = yes\n\nTo help prevent spoofing, you can also create a map file of SASL login\nnames which are allowed to use specific envelope sender (MAIL FROM)\naddresses.  If you choose to do this, you also have to tell Postfix to\nreject addresses which don't match login names:\n\n# prevent spoofing by authenticated users\nreject_sender_login_mismatch\nsmtpd_sender_login_maps=type:/path/to/file\n\nConfiguration of SASL clients is much simpler.  Postfix itself can be\nmade a SASL client; this is typically useful when roaming users run Linux\non their laptop and need to relay mail back through the organization's\nmain server.\n\nTo enable Postfix to act as an SMTP AUTH client, simply add to\n/etc/postfix/main.cf:\n\n# support authentication (RFC 2557) when relaying through a server\nsmtp_sasl_auth_enable = yes\n\nand tell Postfix where to find the usernames and passwords it should\nuse to authenticate:\n\n# location of passwords for authentication client\nsmtp_sasl_password_maps = type:/path/to/file\n\nThe file itself should have the format:\n\ndestination     username:password\n\nwhere destination is the name of the server, and username:password are\nthe username and password which should be presented to that server to\nauthenticate when connecting to it as a client.\n\nOptionally, the authentication methods to be used can be specified for\nthe Postfix client, just as they can be for the Postfix server:\n\n# disable plaintext and anonymous\nsmtp_sasl_security_options = noplaintext noanonymous\n\nMany popular end-user MUAs can also be configured as SMTP AUTH clients.\nClients capable of this supplied with Red Hat include pine, Netscape,\nand Mozilla.\n\nOther Sources of Documentation:\n-------------------------------\n\n/usr/share/doc/postfix-\u003cversion\u003e/README_FILES/SASL_README\n\nLocal configuration examples:\n\n/usr/share/doc/postfix-*/samples\n\nPostfix Howtos, Guides and Tips by Ralf Hildebrandt and Patrick\nKoetter can be found at: http://postfix.state-of-mind.de\n\n------------------------------------------------------------------------------\n\nPlease send any comments / corrections to Chris Ricker\n\u003ckaboom@gatech.edu\u003e.  This material can be freely modified and\nredistributed. Additional material provided by John Dennis\n\u003cjdennis@redhat.com\u003e and Dax Kelson \u003cdax@gurulabs.com\u003e.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpkgstore-old%2Flinux-rpm-postfix","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpkgstore-old%2Flinux-rpm-postfix","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpkgstore-old%2Flinux-rpm-postfix/lists"}