It is important that you understand what "relaying" is and why "open relays" are a big problem on the internet. Usually Postfix accepts an email only if one of these criteria match:
- the recipient's email address belongs to a user on your mail server

- the sender is sending the email from within the local network (defined by Postfix's "mynetworks" setting)

- the sender is authenticated (SMTP supports authenticating with a username and password)

For security reasons the following must not be allowed:

Otherwise a spammer could abuse your system to send millions of spam emails.This would waste your bandwidth, annoy many people and get your server blacklisted quickly. Such a relay that is not checking which emails to accept is called an "open relay". Fortunately Postfix makes it hard to become an open relay. Setting the smtpd_recipient_restrictions right (as described below) is very important.
Generally you can define the networks that are allowed to relay through your mail server by setting the mynetworks parameter in your main.cf. Usually you set it to your local network so local users do not need to authenticate:
$> postconf -e mynetworks=192.168.50.0/24
But one case of relaying from outside of your network is important in real-life. Imagine you have a user who is currently not connected to your local network but wants to send out an email to the internet through your mail server. According to the above rules the user would not be able to do that because neither are they on your network nor are they sending an email to one of your domains. You need to find a way to make your remote user be trusted by your mail server. The users will need to send their username and password so you know relaying should be permitted. This is what authenticated SMTP is about. And all decent email clients have that feature built in.
Authenticated SMTP with Postfix has always been a pain. It was done through the SASL (Simple Authentication and Security Layer) library that was part of the Cyrus mail server. It was nearly impossible to debug and threw error messages that were gibberish and misleading. Fortunately starting with Postfix 2.3 we can make Postfix ask the Dovecot server to verify the username and password. And since you already configured Dovecot this is really easy now. Postfix just needs some extra configuration:
$> postconf -e smtpd_sasl_type=dovecot $> postconf -e smtpd_sasl_path=private/auth $> postconf -e smtpd_sasl_auth_enable=yes $> postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_sasl_auth_enable enables SMTP authentication altogether. And the smtpd_recipient_restrictions define rules that are checked after the remote user sends the RCPT TO: line during the SMTP dialog. In this case relaying is allowed if:
- permit_mynetworks: the user is in the local network (mynetworks) or
- permit_sasl_authenticated: if the user is authenticated or
- reject_unauth_destination: the mail is destined to a user of a domain that is a local or virtual domain on this system (mydestination, virtual_alias_domains or virtual_mailbox_domains).
There are further restrictions (smtpd_client_restrictions, smtpd_helo_restrictions, smtpd_sender_restrictions) that get checked during the different states of the SMTP dialog (IP connection, HELO/EHLO command, MAIL FROM command) but for now you should put all restrictions into the smtpd_recipient_restrictions.
Try to authenticate during an SMTP session:
$> telnet localhost smtp
The server will let you in:
Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailtest ESMTP Postfix (Debian/GNU)
Say hello:
ehlo example.com
Postfix will present a list of features that are available during the SMTP dialog:
250-mailtest 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
Send the authentication string with a Base64-encoded password:
auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg==
The server should accept that authentication:
235 2.0.0 Authentication successful
Disconnect from Postfix:
quit
Goodbye:
221 2.0.0 Bye
Authentication works. Well done.
Note
If you have set John's password to something other than 'summersun' you need Base64-encode it yourself. Use:
$> perl -MMIME::Base64 -e \
'print encode_base64("john\@example.com\0john\@example.com\0password")';
Now you can test sending email with authentication enabled. To make even your local network untrusted temporarily you can set:
$> postconf -e mynetworks= $> postfix reload
Restart Postfix (/etc/init.d/postfix restart). Fire up your mail program and watch your mail.log (tail -f /var/log/mail.log) while you send an email to a domain on the internet. I recommend you send a test email to devnull@workaround.org which is an email address that will just discard your email. If everything worked well your logfile will show:
postfix/smtpd[4032]: 1234567890: client=..., sasl_method=PLAIN, sasl_username=john@example.com
postfix/cleanup[4040]: 2EAE8379CB: message-id=<...>
postfix/qmgr[3963]: 1234567890: from=<john@example.com>, size=830, nrcpt=1 (queue active)
postfix/smtpd[4032]: disconnect from ...
postfix/smtp[4041]: 1234567890: to=<devnull@workaround.org>,
relay=torf.workaround.org[212.12.58.129]:25, delay=6,
delays=0.09/0.08/5.6/0.23, dsn=2.0.0, status=sent
(250 OK id=1HsPC3-0008UJ-O5)
postfix/qmgr[3963]: 2EAE8379CB: removed
Otherwise in case of an error your logfile might look like:
postfix/smtpd[4032]: connect from ...[10.20.30.40] postfix/smtpd[4032]: warning: ...[10.20.30.40]: SASL PLAIN authentication failed: postfix/smtpd[4032]: lost connection after AUTH from ...[10.20.30.40] postfix/smtpd[4032]: disconnect from ...[10.20.30.40]
Don't forget to set mynetworks back to your network definition:
$> postconf -e mynetworks=192.168.50.0/24 $> postfix reload
Your email program may have warned you that the mail server uses an untrusted SSL certificate. When you installed Postfix Debian created a self-signed SSL certificate for you automatically. The default certificate is sufficient for testing but just like you did for Dovecot you can create a custom SSL certificate. The default certificate is stored at /etc/ssl/certs/ssl-cert-snakeoil.pem and the default private key is stored at /etc/ssl/private/ssl-cert-snakeoil.key. This will create a new certificate/key pair:
$> openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
-keyout /etc/ssl/private/postfix.pem
Same procedure as above when you created a certificate for Dovecot. Just remember to set the "Common Name" to the fully-qualified hostname. You could as well use the same certificate you created for Dovecot if the server name is the same. In that case just use the files /etc/ssl/certs/dovecot.pem and /etc/ssl/private/dovecot.pem below.
Do not forget to set the permissions on the private key so that no unauthorized people can read it:
$> chmod o= /etc/ssl/private/postfix.pem
You will have to tell Postfix where to find your certificate and private key:
$> postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem $> postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem
When you relay through Postfix again you should not get that certificate warning any longer.
By default Postfix will allow that the login data for SMTP authentication is sent in plain text. You better only allow encrypted transmission of the credentials by setting these parameters:
$> postconf -e smtpd_use_tls=yes $> postconf -e smtpd_tls_auth_only=no
What these parameters do is offer (but not require) encryption for SASL authentication to be used so that if you're using the PLAIN or LOGIN SASL methods your passwords aren't transmitted in the clear. When the client initially connects to the server, the AUTH command isn't offered by the server. If the client issues the STARTTLS command and successfully negotiates the TLS connection, the client sends the EHLO command a second time and this time the server offers the AUTH command. This won't require any kind of encryption from clients who don't need to authenticate (i.e. servers that connect to send mail to the domains our server is a final destination for, as opposed to our end users attempting to relay mail through it to external domains).
If you truly do want to forbid unencrypted SMTP connections (I do this on ports 587 and 465), you'd want to use either "smtpd_tls_security_level = encrypt" (for STARTTLS, generally on port 587) or "smtpd_tls_wrappermode = yes" (for SSL encryption from the initial connection on, generally on port 465). You could also set "smtpd_tls_security_level = may" so that TLS encryption is offered but it's not mandatory (so-called opportunistic TLS).
Once you are done you should test if your mail server is safely configured to prevent illegal relaying attempts. On a root shell enter:
$> telnet relay-test.mail-abuse.org
This contacts a very convenient service on the internet which tries to relay emails through your mail server. Give it a moment while it checks your server. If at the end you see something like "System appeared to reject relay attempts" then you are fine.
59 Comments
TLS it is!
Submitted by Anonymous (not verified) on
FYI According to the manpage, smtpd_use_tls is obsolete, and has been superseded by smtpd_tls_security_level. Best practice is to use "smtpd_tls_security_level = may" in main.cf, the other two options ("smtpd_tls_security_level = encrypt" for submission, and "smtpd_tls_wrappermode = yes" for ssmtp) are already in master.cf by default (although both are commented by default, so needs uncommenting, if ssmtp and submission should be enabled, which surely is a good idea, especially if you want to use submission as the workaround for sent emails not being checked by spamass-milter, when you decide to abandon amavis in favor of the milters, like I did).
For everyone Who has had problems with smtp authentication
Submitted by Anonymous (not verified) on
Ok guys,
First of all I'd have to thank the poster of this tutorial and the people who have left their comments here to help others.
As many of you have discovered, with newer versions of debian / ubuntu, such as karmic, this gets to major road block. That is the smtp auth plain command won't work, and you cannot use smtp on your local mail clients either. Here's why:t
saslauth is called to use a pam authentication and it doesn't know where to look and you'll be failed.
After extensive searching (over 48 hours of straight searching) and trying to debug, I found this link on howtoforge: http://www.howtoforge.com/virtual-users-domains-postfix-courier-mysql-squirrelmail-ubuntu8.10
With some modifications of the page 2, we can finally get the smtp to work:
[1] edit /etc/default/saslauth and modify the respective fields:
START=yes
[2] create a file: /etc/pam.d/smtp and add these two lines:
[3] create a file: /etc/postfix/sasl/smtpd.conf and add these lines:
[4] then execute this shell command:
adduser postfix sasl
[5] modify /etc/postfix/main.cf and set
smtpd_tls_auth_only=no
[6] Then restart postfix and saslauthd
/etc/init.d/postfix restart
/etc/init.d/saslauthd restart
---------------------------------------------------------------
There you go. Now smtp is working.
Good luck to everyone.
We don't use saslauthd
Submitted by Christoph Haas on
Thanks for your comment. But note that this tutorial uses Dovecot for authentication and not saslauthd. I would recommend against using it if possible. (You shouldn't believe everything you read on h*wt*f*rge. :) )
Dovecot authentication
Submitted by Anonymous (not verified) on
Dovecot authentication doesn't seem to work on Karmic (Ubuntu 9.10). I'd really appreciate any help on how to resolve this :-)
503 5.5.1 Error: authentication not enabled
Submitted by Anonymous (not verified) on
This could be the problem:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/493667
quote:
smtpd_tls_auth_only = yes means it will only offer auth if you connect vial TLS (which you aren't doing when you telnet) so it is correct to not offer it.
Postfix is chrooted
Submitted by Anonymous (not verified) on
This is a simple issue:
Postfix is chrooted so it can't find the file /var/run/dovecot/auth-client
socket listen { client { path = /var/spool/postfix/private/auth ... } }works great so far...
Thank you...
Submitted by dooobie (not verified) on
...for spotting that.
My question is: How to make
Submitted by Anonymous (not verified) on
My question is: How to make postfix ask for authentication even if the recipient's email address belongs to a user on your mail server?
Thanks for any help you will offer…
Gabble
Is that a good idea?
Submitted by Christoph Haas on
Other email servers don't authenticate. So wouldn't that mean that you don't get any more email from public mail servers?
I'll try to explain myself
Submitted by Anonymous (not verified) on
I'll try to explain myself better (please forgive my bad English): my SMTP does not ask for authentication if the recipient is inside any virtual domains of the server.
Let's say my mailserver has both example.com and domain.biz in its virtual domains table.
User john@doe.com (doe.com is an external domain) then emails kate@example.com using domain.biz as SMTP.
SMTP domain.biz does not ask john@doe.com for authentication because example.com is in its virtual domains table, and relays the email.
I would like to avoid such behaviour… any hint?
Gabble
But...
Submitted by Christoph Haas on
I understand what you want to prevent. But imagine this:
I (john@doe.com) want to send an email to kate@example.com. So I send the email to my mail server. My mail server checks the MX record of example.com and figures out that the email has to be sent to your mail server. So my mail server will make an SMTP connection to your mail server and try to deliver the email. Imagine what happens if your email server rejected my email server because it's not authenticated. My mail server doesn't know any credentials (username/password) that would be needed to deliver the email to your server.
Whether an email is sent from a living person using a mail client or from some mail relay on the internet cannot be distinguished. Both use SMTP. A user may be able to use credentials. But any mail server on the internet will try without.
Christoph
This sounds clear and
Submitted by Anonymous (not verified) on
This sounds clear and reasonable, thank you Chris!
Anyway… I have been told that EIMS (Eudora Internet Mail Server) is able to distinguish and asks for authentication only to MUAs. I have not verified myself such thing, but comes from a friend of mine who runs a ISP with EIMS.
Is anybody able to confirm this?
Gabble
only allow specific users to send mail after authenticating
Submitted by Anonymous (not verified) on
I am wondering how to install following to my mailserver.
The current situation:
Having many users, but I do not allow SMTP. So the users can only receive email. They cannot send email from my server with remote program like Thunderbird. They can only send with Squirrelmail as being local user.
What I want:
I want to activate the Authenticated SMTP, but only to some users. Not to everybody, like in this tutorial.
Is there a simple way? For example to add a record to my "virtual_use" table, that contains a: "yes" or "no".
If "yes" he can use authenticated smtp. If "no" he cannot.
Can this be done by altering or adding queries in the postfix .cf files?
Of yes, then what should I alter ?
Only a hint
Submitted by Anonymous (not verified) on
You can add a additional colum in the user-table, something like
"smtp" (1|0)
the mysql-query used for sasl_auth has to ask for it with an additional "AND smtp ="1"
If you want to disallow sending mail via thunderbird or so, put an 0 into the fild, so the query will not give an poitive result.
Could you please give
Submitted by Anonymous (not verified) on
Could you please give more than a hint? I get relay access denied when accessing IMAP from an external mail client. Webmail works perfectly fine. Too noob to figure it out after several hours of googling.
In this setup every
Submitted by Anonymous (not verified) on
In this setup every authenticated user can send mails with arbitrary sender-addresses. This in my opinion should be improved.
So I added the following lines to my /etc/postfix/main.cf:
smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-login-maps.cfsmtpd_sender_restrictions = reject_unknown_sender_domain,reject_non_fqdn_sender,reject_sender_login_mismatch
Now create and edit the file /etc/postfix/mysql-sender-login-maps.cf:
user = mailserverpassword = XXX
hosts = 127.0.0.1
dbname = mailserver
query = ( SELECT GROUP_CONCAT( a.`destination` ) FROM `virtual_aliases` a, `virtual_domains` d WHERE a.`source`='%s' AND a.`domain_id`=d.`id` AND d.`name`='%d' ) UNION ( SELECT `email` FROM `virtual_users` WHERE `email`='%s' )
You can test if you get a valid username with postmap -q email@domian.tld mysql:/etc/postfix/mysql-sender-login-maps.cf
You should get the username (e.g. normally the E-Mail-Address you requested) or if you have a redirect the redirected-address. But this is no problem because there is no user with this address - an example:
You have the address test@test.de which is also the username. You have an alias test2@test.de which will be redirected to test@test.de and finally you have an alias whicht sends every mail to test@test.de to another@mail.de. So if you do a postmap with test@test.de you will get another@email.de,test@test.de. If you do a postmap with test2@test.de you will get test@ŧest.de. If you do it with another@email.de you will get nothing. So it is possible to send with your alias-addresses but not with any address.
I hope you got what I meant in case you didn't please ask in German, that's the langauge I speak and understand :-D
Mail from outside not coming in
Submitted by Anonymous (not verified) on
I've set the smtpd_recipient_restrictions like in this tutorial:
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
But if someone else sending an email to me, it is always rejected.
I tested this with telnet and a sender outside of my network and my (virtual) domains. If the sender is outside, the mail is always rejected. Whats wrong here?
Logs?
Submitted by Christoph Haas on
What is the error message you get in the logs?
Authenticate Smarthosts?
Submitted by Anonymous (not verified) on
I wonder if there is a way to authenticate a smarthost (e.g. an branch office w/ dynamic IP) in a way that a not any MUA needs to atuthenticate (like http://postfix.state-of-mind.de/patrick.koetter/smtpauth/smtp_auth_mailservers.html)
So I don't need to configure any MUA and can centralize some MTA stuff.
Any Idea?
SMTP client authentication
Submitted by Christoph Haas on
Whether a server or a client is using SMTP authentication doesn't make a difference. You should look at the Postfix documentation on SMTP client authentication. My situation is similar. At home I'm on a dynamic IP address and forward all emails to my dedicated Debian server in a computer center which is in turn sending out the emails. I can't send directly from home because most mail servers would reject my email due to dynamic IP blacklists.
Heureka!
Submitted by Anonymous (not verified) on
AHA that#s how to do it :).
This way worked for another postfix configured as smarthost where the relay server is configured according this great tutorial:
needed packages (debian ;) libsasl2-modules libsasl2-2
main.cf:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_type = cyrus
smtp_sasl_security_options =
relayhost = [FQDN.of.relay.mta]
/etc/postfix/sasl_passwd:
FQDN.of.relay.mta email_from_virtual_users_table_entry:cleartextpassword
postmap /etc/postfix/saslpass
postfix restart
i decided for my scenario that email_from_virtual_users_table_entry is the hostname of the box which will act as a smarthost and not like a normal user user@domain.tld
Very nice tutoria! but have some problem
Submitted by Anonymous (not verified) on
Check $mydestination
Submitted by Christoph Haas on
The error message is just about what is says. Your myown.com domain is listed both as a local domain (mydestination) as well as a virtual mailbox domain.
Run
postconf mydestinationand you will probably see that it is set there.
Thank you so much...
Submitted by Anonymous (not verified) on
Yes or No?
Submitted by Anonymous (not verified) on
I suppose that instead of postconf -e smtpd_tls_auth_only=no the correct one settings to hide AUTH until STARTTLS successfully negotiates the TLS connection is postconf -e smtpd_tls_auth_only=yes.
Dovecot authentication
Submitted by Anonymous (not verified) on
Hallo
Erst mal Danke für die super Anleitung. Konnte schon einiges lernen.
Da mein schriftliches Englisch nicht ausreicht, versuche ich es mal auf Deutsch.
Leider komme ich mit der "authentication" nicht weiter. Bis dorthin läuft alles einwandfrei.
Doch beim versuch "telnet localhost smtp" austzufüchren erhalte ich die Fehlermeldung:
5035.5.1 Error: authentication not enableed
Ich habe schon einiges probiert, weiss jedoch beim besten Willen nicht mehr, wo ich suchen soll um das Problem zu lösen.
Es wäre super, wenn mir jemand weiter helfen könnte.
Danke für jede Hilfe in diese Richtung
Hansruedi
Hallo, HR… direkt
Submitted by Christoph Haas on
Hallo, HR...
direkt nach einem "telnet localhost smtp" kommt ein "5035.5.1 Error: authentication not enableed"? Kann ich mir gar nicht vorstellen. Du müsstest mit einem "220…" begrüßt werden. Schau bitte auch mal in dein /var/log/mail.log, ob du dort verdächtige Meldungen entdeckst.
fatal: no SASL authentication mechanisms
Submitted by Anonymous (not verified) on
If you also get warning:
Submitted by Anonymous (not verified) on
If you also get warning: SASL: Connect to private/auth failed: Permission denied, then you should propably check /var/spool/postfix/private/auth file and it's permissions.
It should belong to postfix, not root.
Failure during SMTP connect
Submitted by Anonymous (not verified) on
Hi there,
first of all thanks for the great tutorial. Keep up the good work!
After adding TSL support SMTP stopped working. When connecting I get those messages in the mail.log:
postfix/smtpd[30150]: connect from 123.vie.surfer.at[123.123.123.123]
postfix/smtpd[30150]: SSL_accept error from 123.vie.surfer.at[123.123.123.123]: -1
postfix/smtpd[30150]: lost connection after CONNECT from 123.vie.surfer.at[123.123.123.123]
postfix/smtpd[30150]: disconnect from 123.vie.surfer.at[123.123.123.123]
when connecting trought telnet localhost smtp I simple get
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
ehlo myhost.com
Connection closed by foreign host.
and in /var/log/mail.log:
postfix/smtpd[14109]: SSL_accept error from localhost.localdomain[127.0.0.1]: -1
postfix/smtpd[14109]: warning: TLS library problem: 14109:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:562:
postfix/smtpd[14109]: lost connection after CONNECT from localhost.localdomain[127.0.0.1]
postfix/smtpd[14109]: disconnect from localhost.localdomain[127.0.0.1]
any ideas?
Authenticated SMTP with MacOS X Mail.app
Submitted by Anonymous (not verified) on
Thanks! It works for me too.
Submitted by Anonymous (not verified) on
Thanks! It works for me too.
Also check "trust" settings if using self-signed
Submitted by MikeR (not verified) on
Further note for OS/X mail.app (Snow Leopard):
If you are connecting to a server with a self-signed certificate ("cobbler's children have no shoes ..."), and you're told that "mail can't verify the identity ...", look for a trust-settings checkbox at the bottom of that dialog box.
If you don't see the checkbox, press "details." What you need to do is to tell OS/X to trust this certificate for the mail app. You'll be asked for your login password, and then the certificate will be stored in "Keychain Access." You'll see it there, probably for "localhost," and when you click on it, you should see at the top of the Keychain Access page, "this certificate is trusted for 'mailserver_name'."
If you get stuck, very-quickly ask your mail-server guru to "tail" the server-log to find out what their SMTP server is saying. mail.app probably won't tell you nothin'.
Other useful voodoo...
To check SSL tunneling to the server:
openssl s_client -connect your_mailserver_name:465
... then try "ehlo your_identity" and see if the SMTP server's reply includes "STARTTLS." If so, and as-expected, just quit.
To check STARTTLS:
openssl s_client -connect your_mailserver_name:587 -starttls smtp
In my case, this second command timed-out, without further comment. Presumably that's what was happening to mail.app also.
After changing the trust-settings, both commands (and mail.app) worked immediately.
Now you know!
Multiple SMTP Hostnames / Multiple SMTP certs
Submitted by Anonymous (not verified) on
Great to hear you like the
Submitted by Anonymous (not verified) on
Great to hear you like the tutorial. You are hitting a common problem here. But the names you see in the mail headers are derived from DNS lookups. If you wanted to remedy that you would have to use one IP address per domain. That would not be feasible. For that reason many ISPs have some dummy domain to send email from if the customers should not see at a glance who is the ISP.
In my opinion that's not really a problem. Few users will read the headers. And most of them won't even know what headers are. :)
And, yes, that concludes the certificate issue, too. Unfortunately.
Thanks for the quick reply! I
Submitted by Anonymous (not verified) on
warning: SASL: Connect to private/auth failed: No such file or .
Submitted by Anonymous (not verified) on
Anyone can help me!
I get this error after this chapter:
warning: SASL: Connect to private/auth failed: No such file or directory
fatal: no SASL authentication mechanisms
there are /var/spool/postfix/private/auth
Whats problem?
warning: SASL: Connect to private/auth failed: No such file or .
Submitted by Anonymous (not verified) on
I had the same problem and found a solution.
It is just incorrect path in line "smtpd_sasl_path = private/auth"
I'm using dovecot version 1.2.12 and its default configuration for auth client goes as follows:
client { # The client socket is generally safe to export to everyone. Typical use # is to export it to your SMTP server so it can do SMTP AUTH lookups # using it. path = /var/run/dovecot/auth-client ... }
Fatal Error - requesting a password table?
Submitted by Anonymous (not verified) on
Great guide so far! I'm learning a ton.
With that said, i do have one question. Whenever I restart, I recieve the following fatal error:
May 19 01:23:08 digitalnotions postfix/smtp[3861]: fatal: specify a password table via the `smtp_sasl_password_maps' configuration parameter
What could be causing this? It's driving me mad as I've gone through these instructuions a few time to ensure I didn't mess anything up along the way.
Thanks!
User in same domain
Submitted by Anonymous (not verified) on
If I send email from john@example.com to steve@example.com. It does not need authentication.
But I want john@example.com must authenticate. How can I config it?
Mark
Found Answer???
Submitted by Anonymous (not verified) on
If I set
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,check_sender_access mysql:/etc/postfix/mysql-check_sender_access.cf,reject_unauth_destination
and create /etc/postfix/mysql-check_sender_access.cf
user = mailuser
password = mailuser2009
hosts = 127.0.0.1
dbname = mailserver
query = SELECT '554 Access denied' FROM virtual_domains WHERE name='%s'
Is it good idea to do like this?????
Mark
deny in port 25 the access to domain except if sasl authenticate
Submitted by Claudio Jr (not verified) on
I use this feature in my server, but in a static file.
I plaining to migrate to mysql server, but in production enviroment don´t is possible.
The query form is valid? Has any tested this?
Thanks
Receiving mail is OK, but I can't send.
Submitted by Anonymous (not verified) on
Thanks for the tutorial -- I found a couple of lower quality spin-off tutorials first, but I'm glad I finally found the real deal.
I can receive e-mail on my Thunderbird 3.0.6 client fine, but I can't send e-mail. I see the following warnings in /var/log/mail.log:
Aug 23 13:30:10 foo postfix/smtpd[16548]: warning: cpe-67-250-21-200.nyc.res.rr.com[67.250.21.200]: SASL PLAIN authentication failed:
Aug 23 13:30:12 foo postfix/smtpd[16548]: warning: cpe-67-250-21-200.nyc.res.rr.com[67.250.21.200]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Any idea how to trouble shoot this?
Thanks,
TM
[SOLVED] Receiving mail is OK, but I can't send.
Submitted by Anonymous (not verified) on
Turns out that my server set up was fine. The problem was with my Thunderbird client. Specifically, my outgoing SMTP configuration had user=foo instead of user=foo@bar.baz like my server was expecting. Unrelatedly, I read in another thread that UGFzc3dvcmQ6 is unicode for "password".
There really hasn't been good
Submitted by Anonymous (not verified) on
There really hasn't been good treatment of master.cf from a few days searching online.
5035.5.1 Error: authentication not enabled
Submitted by Anonymous (not verified) on
I had this problem too, but in the end this is a simple misunderstanding.
If you have enabled:
smtpd_tls_auth_only = yes
You will not see any AUTH listed when connecting and doing an ehlo. In addition any attempt to auth will be met with the error
035.5.1 Error: authentication not enabled
This is how it should be! – Postfix will not display options for smtp authentication unless a TLS security is used to connect.
Try connecting with:
openssl s_client -connect localhost:25 -starttls smtp
Now you will see the 250-AUTH PLAIN LOGIN on ehlo and you will be able to auth.
If you do not wish to use tls, ensure that the smtpd_tls_auth_only is disabled.
I hope this helps.
Big thumbs up to Christoph for an excellent tutorial – I am using this now ubunto 10.4 with minor modification.
Sender address rejected: not owned by user
Submitted by Anonymous (not verified) on
Unable to get Authenticated SMTP to work
Submitted by Anonymous (not verified) on
farstrider:~# telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 xxxx.xxxxx..com ESMTP Postfix (Debian/GNU)
ehlo gmail.com
250-xxxx.xxxxx..com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth plain cGF5cGFsQGJlZmFuY3kuY28udWsAcGF5cGFsQGJlZmFuY3kuY28udWsARzBvZ2xlUGwzeA==
503 5.5.1 Error: authentication not enabled
What am I likely to be missing?
using SSL to connect
Submitted by Anonymous (not verified) on
If you want to use smtpd_tls_wrappermode = yes you must not forget to uncomment the respective lines in /etc/postfix/master.cf:
smtps inet n - - - - smtpd
-o smtpd_tls_wrappermode=yes
similar for smtpd_tls_security_level = encrypt"
Still get the Certificate warning
Submitted by Anonymous (not verified) on
Hello,
the first time I use an account with thunderbird I still get the certificate warning using an untrusted SSL certificate. Outlook Express doesn't show the warning. I created a new certificate for Dovecot and use the for Postfix too. How can I get rid of this message?
Thank you very much!
Pages