Tim Pleiman wrote:
On Tue, July 14, 2009 11:07 am, Eric Shubert wrote:
Tim Pleiman wrote:
On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote:
Aleksander Podsiadly wrote:
W dniu 13.07.2009 22:16, Tim Pleiman pisze:
/var/qmail/control/me contains the primary server mail domain name,
e.g:
mail.<servername>.org
Tim
It should be the same as result of `hostname`, just the servername.
Not
,,mail.<servername>.org'' but FQDN servername with all dots. Not the
value of CNAME, but the name from record A, the same as the name from
PTR record. IMO it's the best, clear and proper configuration.
My toaster has the fqdn value in there, but I can't say for sure where
it comes from.
I can say that it does not come from `hostname --fqdn` (although I
agree
with Alex that this is the value it should reflect).
Oh, here it is. Looks like it comes from the
/var/qmail/control/helohost
file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost
--
-Eric 'shubes'
Yes it does. However, "helohost" defaults to "me" if not specified in
the
control files. And, it should pick up "me" as I have it specified, but
it
does not (I also tried specifying helohost in addition to the correct
me--everything with the same name). In the case of localhost sends (as
in
this case from Squirrelmail), I believe it should ideally pick up the
virtual domain that it is sent from in vpopmail, which would be
"testdomain.com" at this stage.
Again, it only happens in the second stage of the header during a
localhost send process. All the other HELOs are correct. Upon endless
adjustments, I think it may be coming from the CHKUSER patch. I did
manage
to get the "unknown" portion of the HELO changed to say "localhost"
instead by removing the "-H" option from tcpserver. So now I get:
from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1)
from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1)
The "unknown" goes away, and once this is changed, the smtp daemon logs
also reflect the change, referring also to "localhost" instead of
"unknown":
2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1
2009-07-13 22:17:19.156819500 tcpserver: ok 6969
mail.<servername>.org:127.0.0.1:25 localhost:127.0.0.1::43932
2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from
<[email protected]::> remote
<[xx.xxx.xxx.xxx]:localhost:127.0.0.1> rcpt <> : sender accepted
2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from
<[email protected]::> remote
<[xx.xxx.xxx.xxx]:localhost:127.0.0.1> rcpt <tpleiman@<domainname>.net>
:
client allowed to relay
INSTEAD OF:
2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1
2009-07-10 17:18:30.503012500 tcpserver: ok 32023
mail.<servername>.org:127.0.0.1:25 :127.0.0.1::41168
2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from
<[email protected]::> remote
<[xx.xxx.xxx.xxx]:unknown:127.0.0.1>
rcpt <> : sender accepted
2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from
<[email protected]::> remote
<[xx.xxx.xxx.xxx]:unknown:127.0.0.1>
rcpt <tpleiman@<domainname>.net> : client allowed to relay
I believe HELOs typically should be picked up from the static
configuration files in /var/qmail/control and I can't figure out for the
life of me where (chkuser?) is pulling this HELO name from when it is a
simple "localhost" send from the same box--e.g. remote and localhost are
the SAME machine, and why it won't at least just pick up the "helohost"
or
"me" from the control files.
At any rate, everything else is working fine. Incomings are are all
processing great, and I don't think this is that big of a deal as server
to server communications and HELOs are correct, but it would be nice to
clean this up so the headers on outbound sends are correct during this
internal localhost transaction process for localhost sends from
SquirrelMail.
Am I just missing something really stupid here?
Thanks again!
You're all over the solution. The only ones that are messed up are the
ones from squirrelmail, so don't you think it's likely that squirrelmail
is where the solution lies? ;)
I don't have your solution, but I can point you in the right direction.
I just ran a test, and on my system it appears that the (HELO
mail.shubes.net) is indeed coming from squirrelmail somehow. The only
place I have mail.shubes.net specified is in the url I used for
accessing squirrelmail. So I tried accessing squirrelmail with
test.shubes.net, and indeed I get (HELO test.shubes.net).
Now I admit that I've tweaked my config_local.php file from the stock
values, mainly because I'm running dovecot in place of courier. I didn't
see anything there that I thought would effect this behavior though.
So do some digging into SM, and I think you'll find the solution.
--
-Eric 'shubes'
Eric,
Indeed, that's exactly what's going on here. It seems that particular HELO
is being picked up from the actual URL domain that you use for login. So,
if you login via IP address, that's what you get in the HELO. Squirrelmail
is passing this on, and has always done so apparently, but I just never
noticed before, as it always resolved once the domain URL was used (duh!).
Removing -H from tcpserver options, however, does eliminate the "unknown"
from this HELO position and then references it correctly as "localhost."
(I needed to remove the -H option from tcpserver anyhow because I want to
add partial rDNS lookups and use them in conjunction with rhost_check in
non-paranoid mode, which I will compile and implement in conjunction with
RBLSMTPD separately--a topic which I'll post here shortly). Others may
wish to do this as well depending on their overall setup (without -H,
tcpserver runs with its default -h option), if they can, so that localhost
is referenced correctly at this stage.
I had pointed DNS for one of my spare domains to this server's IP late
last night to test inbound mail. So, after your suggestion here, I just
used that domain URL to login to Squirrelmail instead of the IP address of
the server, and bingo, the HELO issue disappeared.
So, it was something pretty stupid and straightforward after all.
Great! Thanks!
Tim
I'm glad you've paid close attention to details, Tim.
Two things I'd like to share.
FYI, I've brought up the issue of the -H option on the development list.
We may be getting rid of that in the stock toaster, depending on the
result of that discussion.
Also, you might consider using spamdyke instead of implementing rDNS and
rhost_check in native qmail. The spamdyke package all that and much much
more, is robust and easily configured. You can install it by running the
qtp-install-spamdyke script in the qmailtoaster-plus package. See
http://wiki.qmailtoaster.com/index.php/Spamdyke
--
-Eric 'shubes'
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
