On Saturday, May 1, 2004 at 8:25:34 PM you wrote (at least in part):
> I tried without the SMTP AUTH Patch
> so I recompiled the netqmail-1.05,
> remove the vchkpw part from the qmail-smtpd/run file,
Compile with SMTP AUTH patch and nevertheless keep vchkpw part
removed. Test (with and without SMTP; to a domain that is in
Insert vchkpw again. Test again, but don't authenticate but send a
mail to a domain that is in 'rcpthosts'.
You'll see the messages pass through. Than test again with
authentication. You'll see the '@IP' part again in received headers,
that's because the SMTP-AUTH patch set's TCPREMOTEINFO.
But all this is not responsible for a line like this:
From: "tino" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
To: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
as you presented them in your mail <mid:[EMAIL PROTECTED]>
THIS is set by MUA, the same applies to:
Return-Path: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
Your MUA sent:
MAIL FROM:<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
Even if we'd assume netqmail+SMTP_AUTH_+vpopmail would modify
Return-Path (envelope from) it'd NEVER EVER modify 'From:' or 'To:'
So please test a full patched, full configured (incl. vchkpw)
installation using command line and telnet:
$> perl -MMIME::Base64 -e 'print encode_base64("username");'
$> perl -MMIME::Base64 -e 'print encode_base64("password");'
$> telnet <HOST> 25
C: EHLO _
S: 250 ...
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
S: 334 UGFzc3dvcmQ6
S: 235 ok, go ahead (#2.0.0)
C: MAIL FROM:<[EMAIL PROTECTED]>
S: 250 ok
C: RCPT TO:<[EMAIL PROTECTED]>
S: 250 ok
S: 354 go ahead
C: From: "tino" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
S: 2xx ...
Replace 'username' and 'password' in Perl script line with working
values, remember to masquerade '@' in any of these strings with '\'
(i.e. a username of '[EMAIL PROTECTED]' will be '[EMAIL PROTECTED]').
'S:' indicates lines the server sends, 'C:' indicates lines you
should type / copy&paste or enter any other way for them being sent
to the server.
I'm quite sure this test will success and than you know it's the MUA
that sends these cryptic envelope from, From: and To: strings. The
'@IP' in 'Received:' lines is not part of your problem, as it is never
used for any delivery action, neither forward nor for the bounce.
What do you mean, QWK? It took me over an hour to read!