On Tue, July 14, 2009 5:25 pm, Eric Shubert wrote:
> 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'
>
You know, I do have qmailtoaster plus installed, and I used it to update
the entire base package just a couple weeks ago (had script installed
these servers for early testing in May with an earlier QMT release).
I did review Spamdyke, but I guess I hadn't paid attention to the rDNS
lookup option there as I sort of immediately ruled it out because of the
graylisting. I don't care for graylisting myself as I hate having my
queues waiting on other people's graylisting, and I know that some of my
clients would go berserk if they even have to to wait 5 minutes for mail
delivery. (I know that's nuts, considering the fact that default delivery
times were like 7 days in Qmail not so many years ago. My first mail
server was actually a UUCP mail server back in the mid-nineties, believe
it or not).
Anyway, I'm assuming it's possible to turn off graylisting in the
spamdyke.conf file, yes? All the features listed at spamdyke.org are
re-configurable/tweakable in spamdyke.conf after installation?
Thanks!
Tim
--
Tim Pleiman
Bravo Systems Technologies
"Advanced Open Source Solutions for Business"
Chicago, IL USA
---------------------------------------------------------------------------------
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]
