a patch about xclient

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

a patch about xclient

jeff geng
hi, list:
I want to write a patch for postfix.2.5.2. It is mainly for nginx smtp proxy's xclient function. nginx support parameters as follows:
PROTO,HELO,ADDR,LOGIN,NAME(you can found it in http://wiki.codemongers.com/NginxMailProxyModule?highlight=%28xclient%29), however, postfix doesn't support login. This lead to incompatible between niginx and postfix, so I want to add this parameter to postfix.2.5.2.

Now, there is a doubt. After adding this patch, we can authenticate with nginx and needn't to authenticate in postfix again(only configure postfix as a open relay, set smtpd_sasl_auth_enable = no) , but I also want to use reject_sender_login_mismatch to reject some spamers. 
This need to set smtpd_sasl_auth_enable = yes.

I think of two options´╝Ü
1.add a configuration such as smtp_xclient_login_enable = yes and set smtp_sasl_auth_enable = no. This can ingnore postfix's authentication and check reject_unauth_sender_login_mismatch.
2.set smtp_sasl_auth_enable = yes. After xclient overrides state->sasl_username, ingnore the real operation of the postfix authenticate process, do checking reject_unauth_sender_login_mismatch.

Please advise me which option is better and can be adopted by postfix orgnization? Thanks.

jeff x.geng

Reply | Threaded
Open this post in threaded view
|

Re: a patch about xclient

Wietse Venema
There are a couple issues to consider.

1) The code that manages SASL attributes has been rewritten for
Postfix 2.6 (and this code will probably be revised again before
Postfix 2.6 is done).  Patches relative to Postfix 2.5 are therefore
not useful.

2) If we add more attributes to XCLIENT, then the current code
needs to be reorganized. It's wrong to duplicate code from
smtpd_peer_init(), smtpd_sasl_auth_cmd() etc. inside the XCLIENT
handler. There will be memory leaks, inconsistencies, and other
bugs.

Instead, the XCLIENT handler would have to call code inside
smtpd_peer.c, smtpd_sasl_proto.c, etc. that manages the data. For
example, the work would be done by functions called smtpd_peer_force(),
smtpd_sasl_auth_force(), etc., and those functions would also be
responsible for attribute syntax checks.

The XCLIENT handler would then become a table-driven skeleton
function that knows nothing about the XCLIENT attributes that
Postfix supports.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: a patch about xclient

jeff geng
hi, Wietse:
Thank you for your patience with the answer.
These days I completed the patch for nginx xclient login method. I have taken note of the what you have mentioined.

Because manages SASL attributes has been rewritten for Postfix 2.6, so I do a minimum of changes.  And the first method (add smtp_xclient_login_enable parameters) you do not agree, so  I adopted the second approach. And facts have proved that the second one is a simple way.

In my method, I set smtp_sasl_auth_enable = yes, and postfix will check reject_sender_login_mismatch. And if I would use nginx xclinet login method, the nginx have authenticated the sender, so  postfix no longer need to authenticate.  In other words, I would set smtp_sasl_auth_enable and want postfix work as an open relay.

I have reviewd how postfix authenticate. In smtpd_sasl_glue.c:smtpd_sasl_authenticate, postfix set state->sasl_username and state->sasl_method when authentication passed. However, this is not needed in nginx mode because nginx has authenticated. So  smtpd_sasl_authenticate will never be executed.

But the issue is I want postfix let the sender have't authenticated in postfix go through.  I look into smtpd_check.c:generic_checks "Recipient mail address restrictions." section, we will see if we set smtpd_recipient_restrictions = permit_sasl_authenticated, postfix will involk smtpd_sasl_proto.c:permit_sasl_auth. In this function, postfix process like this:if (state->sasl_method && strcasecmp(state->sasl_method, "anonymous")). So if we let postfix pass sender through, We only need to set state->sasl_method.

At last, in smtpd.c:xclient_cmd,  I add a new xclient parameter:XCLIENT_LOGIN. if nginx pass the LOGIN parameter into postfix,  it whill run UPDATE_STR(state->sasl_method, "xclient");. I set state->sasl_method=xclient, it means xclient is a new sasl authenticate method (nginx has authenticated the user, and postfix need not to authenticated again).

Thank you again.

jeff x.geng

2008-7-11

Next is my test result (you can omit it, only as proof of it worked):
login sender and mail from match(nginx):
[root@localhost nginx]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 localhost.localdomain ESMTP ready
ehlo example.com
250-localhost.localdomain
250 AUTH PLAIN LOGIN
auth login
334 VXNlcm5hbWU6
dGVzdDFAZXhhbXBsZS5jb20=
334 UGFzc3dvcmQ6
MTExMTEx
235 2.0.0 OK
mail from:<[hidden email]>
250 2.1.0 Ok
rcpt to:<[hidden email]>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject:test
.
250 2.0.0 Ok: queued as 2AFA370D20
quit
221 2.0.0 Bye
Connection closed by foreign host.


login sender and mail from mismatch(nginx):
[root@localhost nginx]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 localhost.localdomain ESMTP ready
ehlo example.com
250-localhost.localdomain
250 AUTH PLAIN LOGIN
auth login
334 VXNlcm5hbWU6
dGVzdDFAZXhhbXBsZS5jb20=
334 UGFzc3dvcmQ6
MTExMTEx
235 2.0.0 OK
mail from:<[hidden email]>
250 2.1.0 Ok
rcpt to:<[hidden email]>
553 5.7.1 <[hidden email]>: Sender address rejected: not owned by user [hidden email]

postfix xclinet command:
[root@localhost bin]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 gengxin.sohu.net ESMTP Postfix
ehlo example.com
250-gengxin.sohu.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH LOGIN
250-XCLIENT NAME ADDR PROTO HELO REVERSE_NAME PORT LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
XCLIENT PROTO=ESMTP HELO=example.com ADDR=127.0.0.1 LOGIN=[hidden email] NAME=[UNAVAILABLE]
220 gengxin.sohu.net ESMTP Postfix


2008/7/7 Wietse Venema <[hidden email]>:
There are a couple issues to consider.

1) The code that manages SASL attributes has been rewritten for
Postfix 2.6 (and this code will probably be revised again before
Postfix 2.6 is done).  Patches relative to Postfix 2.5 are therefore
not useful.

2) If we add more attributes to XCLIENT, then the current code
needs to be reorganized. It's wrong to duplicate code from
smtpd_peer_init(), smtpd_sasl_auth_cmd() etc. inside the XCLIENT
handler. There will be memory leaks, inconsistencies, and other
bugs.

Instead, the XCLIENT handler would have to call code inside
smtpd_peer.c, smtpd_sasl_proto.c, etc. that manages the data. For
example, the work would be done by functions called smtpd_peer_force(),
smtpd_sasl_auth_force(), etc., and those functions would also be
responsible for attribute syntax checks.

The XCLIENT handler would then become a table-driven skeleton
function that knows nothing about the XCLIENT attributes that
Postfix supports.

       Wietse


postfix-2.5-patch03-forxclient (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: a patch about xclient

Wietse Venema
As noted in my initial response, the XCLIENT command handler must
not modify information that is maintained by the SASL subsystem.
Instead, it must call into the SASL subsystem.

I am in the process of stripping the XCLIENT command handler, by
moving the code that manages the client name/address information
to the smtpd_peer subsystem where it belongs.

Features like "XCLIENT LOGIN" must not be implemented by peeking
at the internals of modules. Instead, they must be implemented in
terms of higher-level concepts expressed meaningful APIs.

        Wietse