Postfix nginx support (was: XCLIENT patch for postfix)
jeff geng: Wietse: Happy new year :) We use niginx's smtp function to redirect mail to postfix server. But in postfix, XCLIENT command can't support the LOGIN paremeter. Severial months ago, I write a patch for postfix-2.5.3. Now nginx official website also supply a patch for this situation as followed: http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch also support xforward function. I have adopted the nginx:xclient-login-patch in Postfix 2.9, and have made it easier to use. You can now send XCLIENT LOGIN=username without having to specify smtpd_sasl_auth_enable = yes in main.cf. I think this must be the least painful way to use SASL with Postfix. You still need to compile Postfix with -DUSE_SASL_AUTH because otherwise some data structure fields don't exist, but I don't think that would be a problem. Merry christmas. Wietse
Re: XCLIENT patch for postfix
jeff geng: Wietse: Please see my reply marked as blue. :) jeff geng 2010/1/5 Wietse Venema wie...@porcupine.org jeff geng: Wietse: Happy new year :) We use niginx's smtp function to redirect mail to postfix server. But in postfix, XCLIENT command can't support the LOGIN paremeter. Severial months ago, I write a patch for postfix-2.5.3. Now nginx official website also supply a patch for this situation as followed: http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch also support xforward function. We will be very grateful to you if you can accept these patch (nginx official patch or our patch). Of course, you'd better add this function to your new version. After that We can use new version directly, other than patch the original source manually. Can you explain the following: + int got_login =0; ... + got_login = 1; Why is the got_login variable introduced? It is a write-only variable. We introduce got_login is for the same reason as got_helo and got_proto.It means postfix has got login information from client, and postfix should save the username and password from XCLIENT. Your patch is no code that reads the got_login variable. This this is a dead assignment. #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) ! if (got_proto == 0) ! smtpd_sasl_auth_reset(state); #endif Why test for the PROTO attribute here? What happens when the client sends LOGIN=username before PROTO=SMTP? As documented XCLIENT does not require that attributes are sent in a specific order. This is my mistake. It should be if (got_login == 0 ar_smtpd_sasl_enable(state)) . It means if postfix can't get login This explains why you had a variable that was written to but that was never read. + UPDATE_STR(state-sasl_username, attr_value); + printable(state-sasl_username, '?'); + UPDATE_STR(state-sasl_method, xclient); Why not use the real authentication mechanism? Otherwise, if XCLIENT pass LOGIN parameter, state-sasl_username and state-sasl_method will be updated, postfix will deem it as an authenticated client. So , if nginx pass through LOGIN parameter, postfix should identify it as a authenticated client, but postix XCLIENT can't support this parameter. XCLIENT can support both the login name and the authentication method name, and therefore nginx should pass both to Postfix. Wietse PS I don't use a web browser to read mail, so there is no need to color your responses.
Re: XCLIENT patch for postfix
Wietse Venema: + UPDATE_STR(state-sasl_username, attr_value); + printable(state-sasl_username, '?'); + UPDATE_STR(state-sasl_method, xclient); Why not use the real authentication mechanism? Otherwise, if XCLIENT pass LOGIN parameter, state-sasl_username and state-sasl_method will be updated, postfix will deem it as an authenticated client. So , if nginx pass through LOGIN parameter, postfix should identify it as a authenticated client, but postix XCLIENT can't support this parameter. XCLIENT can support both the login name and the authentication method name, and therefore nginx should pass both to Postfix. I noticed that the nginx reverse proxy implements TLS, so it makes sense to plan for future XCLIENT extensions that propagate TLS attributes, besides the extension for SASL that you introduced with this thread. This means using something like SASL_USER and SASL_METH for the proposed SASL attributes, and TLS_XXX for future TLS attributes, so that there will be no conflicts between the names. I keep whining about the SASL authentication method, because that information is used by the Postfix permit_sasl_authenticated access control feature. It would therefore be wrong to set this to a fixed value like your patch does. Now that I understand how your patch is supposed to work, I can put something into Postfix, but it would help if we can agree on the attribute names and on the protocol details. I am sure that there are a few gotchas when you poke Postfix SASL attributes without proper initialization and cleanup of the Postfix SASL layer, but that can be fixed by adding a few functions to that SASL layer that handle support for proxied attributes. Wietse
Re: XCLIENT patch for postfix
Wietse: If We modify #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) if (got_proto == 0) smtpd_sasl_auth_reset(state); #endif to #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) if (got_login == 0) smtpd_sasl_auth_reset(state); #endif the got_login will be used.But this is not the key issues. If nginx will support SASL_USER and SASL_METH parameters, it would be best. If you can put something into Postfix for current nginx We will be very grateful to you. Thank you. jeff geng 2010/1/6 Wietse Venema wie...@porcupine.org Wietse Venema: + UPDATE_STR(state-sasl_username, attr_value); + printable(state-sasl_username, '?'); + UPDATE_STR(state-sasl_method, xclient); Why not use the real authentication mechanism? Otherwise, if XCLIENT pass LOGIN parameter, state-sasl_username and state-sasl_method will be updated, postfix will deem it as an authenticated client. So , if nginx pass through LOGIN parameter, postfix should identify it as a authenticated client, but postix XCLIENT can't support this parameter. XCLIENT can support both the login name and the authentication method name, and therefore nginx should pass both to Postfix. I noticed that the nginx reverse proxy implements TLS, so it makes sense to plan for future XCLIENT extensions that propagate TLS attributes, besides the extension for SASL that you introduced with this thread. This means using something like SASL_USER and SASL_METH for the proposed SASL attributes, and TLS_XXX for future TLS attributes, so that there will be no conflicts between the names. I keep whining about the SASL authentication method, because that information is used by the Postfix permit_sasl_authenticated access control feature. It would therefore be wrong to set this to a fixed value like your patch does. Now that I understand how your patch is supposed to work, I can put something into Postfix, but it would help if we can agree on the attribute names and on the protocol details. I am sure that there are a few gotchas when you poke Postfix SASL attributes without proper initialization and cleanup of the Postfix SASL layer, but that can be fixed by adding a few functions to that SASL layer that handle support for proxied attributes. Wietse
Re: XCLIENT patch for postfix
jeff geng: Wietse: If We modify #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) if (got_proto == 0) smtpd_sasl_auth_reset(state); #endif to #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) if (got_login == 0) smtpd_sasl_auth_reset(state); #endif the got_login will be used.But this is not the key issues. If nginx will support SASL_USER and SASL_METH parameters, it would be best. If you can put something into Postfix for current nginx We will be very grateful to you. Thank you. I'll give it a try. I looked at nginx and I think it does a good job. Wietse jeff geng 2010/1/6 Wietse Venema wie...@porcupine.org Wietse Venema: + UPDATE_STR(state-sasl_username, attr_value); + printable(state-sasl_username, '?'); + UPDATE_STR(state-sasl_method, xclient); Why not use the real authentication mechanism? Otherwise, if XCLIENT pass LOGIN parameter, state-sasl_username and state-sasl_method will be updated, postfix will deem it as an authenticated client. So , if nginx pass through LOGIN parameter, postfix should identify it as a authenticated client, but postix XCLIENT can't support this parameter. XCLIENT can support both the login name and the authentication method name, and therefore nginx should pass both to Postfix. I noticed that the nginx reverse proxy implements TLS, so it makes sense to plan for future XCLIENT extensions that propagate TLS attributes, besides the extension for SASL that you introduced with this thread. This means using something like SASL_USER and SASL_METH for the proposed SASL attributes, and TLS_XXX for future TLS attributes, so that there will be no conflicts between the names. I keep whining about the SASL authentication method, because that information is used by the Postfix permit_sasl_authenticated access control feature. It would therefore be wrong to set this to a fixed value like your patch does. Now that I understand how your patch is supposed to work, I can put something into Postfix, but it would help if we can agree on the attribute names and on the protocol details. I am sure that there are a few gotchas when you poke Postfix SASL attributes without proper initialization and cleanup of the Postfix SASL layer, but that can be fixed by adding a few functions to that SASL layer that handle support for proxied attributes. Wietse
XCLIENT patch for postfix
Wietse: Happy new year :) We use niginx's smtp function to redirect mail to postfix server. But in postfix, XCLIENT command can't support the LOGIN paremeter. Severial months ago, I write a patch for postfix-2.5.3. Now nginx official website also supply a patch for this situation as followed: http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch also support xforward function. We will be very grateful to you if you can accept these patch (nginx official patch or our patch). Of course, you'd better add this function to your new version. After that We can use new version directly, other than patch the original source manually. jeff geng 2010-1-5 postfix-2.5-patch03 Description: Binary data
Re: XCLIENT patch for postfix
jeff geng: Wietse: Happy new year :) We use niginx's smtp function to redirect mail to postfix server. But in postfix, XCLIENT command can't support the LOGIN paremeter. Severial months ago, I write a patch for postfix-2.5.3. Now nginx official website also supply a patch for this situation as followed: http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch also support xforward function. We will be very grateful to you if you can accept these patch (nginx official patch or our patch). Of course, you'd better add this function to your new version. After that We can use new version directly, other than patch the original source manually. Can you explain the following: + int got_login =0; ... + got_login = 1; Why is the got_login variable introduced? It is a write-only variable. #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) ! if (got_proto == 0) ! smtpd_sasl_auth_reset(state); #endif Why test for the PROTO attribute here? What happens when the client sends LOGIN=username before PROTO=SMTP? As documented XCLIENT does not require that attributes are sent in a specific order. + UPDATE_STR(state-sasl_username, attr_value); + printable(state-sasl_username, '?'); + UPDATE_STR(state-sasl_method, xclient); Why not use the real authentication mechanism? Wietse
Re: XCLIENT patch for postfix
Wietse: Please see my reply marked as blue. :) jeff geng 2010/1/5 Wietse Venema wie...@porcupine.org jeff geng: Wietse: Happy new year :) We use niginx's smtp function to redirect mail to postfix server. But in postfix, XCLIENT command can't support the LOGIN paremeter. Severial months ago, I write a patch for postfix-2.5.3. Now nginx official website also supply a patch for this situation as followed: http://www.citrin.ru/nginx:xclient-login-patch. In additional, my patch also support xforward function. We will be very grateful to you if you can accept these patch (nginx official patch or our patch). Of course, you'd better add this function to your new version. After that We can use new version directly, other than patch the original source manually. Can you explain the following: + int got_login =0; ... + got_login = 1; Why is the got_login variable introduced? It is a write-only variable. We introduce got_login is for the same reason as got_helo and got_proto.It means postfix has got login information from client, and postfix should save the username and password from XCLIENT. #ifdef USE_SASL_AUTH if (var_smtpd_sasl_enable) ! if (got_proto == 0) ! smtpd_sasl_auth_reset(state); #endif Why test for the PROTO attribute here? What happens when the client sends LOGIN=username before PROTO=SMTP? As documented XCLIENT does not require that attributes are sent in a specific order. This is my mistake. It should be if (got_login == 0 ar_smtpd_sasl_enable(state)) . It means if postfix can't get login infomation from XCLIENT, postfix will involk smtpd_sasl_auth_reset to cleanup state-sasl_username and sasl_method. After that, if user want to authenticate, he will authenticate through auth login. + UPDATE_STR(state-sasl_username, attr_value); + printable(state-sasl_username, '?'); + UPDATE_STR(state-sasl_method, xclient); Why not use the real authentication mechanism? Otherwise, if XCLIENT pass LOGIN parameter, state-sasl_username and state-sasl_method will be updated, postfix will deem it as an authenticated client. So , if nginx pass through LOGIN parameter, postfix should identify it as a authenticated client, but postix XCLIENT can't support this parameter.
