ns_sendmail sends the helo part of the SMTP
conversation with a non-FQDN. Many mail servers are
configured nowadays to reject non-FQDN HELO lines
because of spam. ns_sendmail needs to be modified to
send the FQDN of the host AOLserver is running on.
By default ns_sendmail used [ns_info hostname] to get the
helo hostname. ns_info hostname uses the gethostname() to
determine the system's hostname.
There are a few ways to address the problem.
One would be a address this in documentation and the
sample-config.tcl. Instead of using set hostname [ns_info
hostname] using something like set hostname
"my.domain.name". This would be a simple fix.
Modify ns_info hostname (in info.c) to make sure a FQDN is
pulled. Probably the most difficult thing to do and the
least helpful. In general the hostname of the server
running AOLserver will be different that the displayed
hostname. While the hostname of the server might be
kermit.domain.name, the URL will be www.domain.name. With
the vary implementations for dns resolvers on various
systems that could add a level of complexity to things.
Add a ns/parameter "maildomain" to define what domain name
should be used when sending email. This would be the best
setup. ns_sendmail could be modfied to not send mail if the
value is NULL, which would be the deafult.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd be more in favor of defining a "maildomain" parameter to
the config and then having the ns_sendmail code use
ns_config to pull it. Just my two cents on this matter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cleaned up the patch a bit. Instead of throwing and error
if maildomain is not set, it logs an Error. I also cleaned
up removed the string match(s) for the configuration
parameters and replaced them with string length $var < 1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That change can be made, I like to use terse log file to
give people the idea that should really make the change.
Attached is the updated patch against tcl/sendmail.tcl in HEAD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggested something the same to Mat on the AOLserver chat,
sans the logged warning. We should just document (perhaps
in sample-config.tcl) that either ns/parameters maildomain
is used OR [ns_info hostname]. Logging the warning seems
unnecessarily noisy -- especially if you DO just want it to
use [ns_info hostname] it seems silly to have to explicitly
define ns/parameters maildomain as [ns_info hostame] just to
squelch the warning.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The warning should probably point to the file sending the warning, and
include the path to the parameter. Otherwise folks are going to scratch
heads to figure out how to fix the problem.
Is the place for this in "ns/parameters"? Shouldn't each server be
allowed to have their own under "ns/server/servername", maybe falling
back to a default under "ns/parameters"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Q: Is the place for this in "ns/parameters"? Shouldn't each
server
be allowed to have their own under "ns/server/servername",
maybe falling back to a default under "ns/parameters"?
Right now all the configuration parameters for sendmail.tcl
are under ns/parameters, I think adding a new parameter and
having two different places it can be set in the
configuration file is a bit to much. Generally mail servers
that make SMTP connections only have one name they use when
issuing the HELO command. One place for the parameters is
the best way to go.
Modifying the warning to point to the file (sendmail.tcl)
and the parameter to change should probably been done at
start up, but I think adding the configuration change to the
documentation will be enough to get the information out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think Tom brings up a bigger topic for discussion, which is whether or not
ns_sendmail should be virtual server aware. I'd suggest applying the first
patch as is, and then taking on virtual server support as a new task.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took the suggested into account and create the following:
Added paramater for ns_sendmail helohost
ns_sendmail to from subject body ?extraheaders? ?bcc? ?helohost?
When ns_sendmail is called, it will check if helohost is
sent, if not it will set hello host to ns_config
"ns/server/[ns_info server]" maildomain and call _ns_sendmail.
_ns_sendmail will if helohost is null. If null it will
check for ns/parameters maildomain, if still null it will
use [ns_info hostname].
This will allow people to set helohost in their coding, if
they choose, setup a global default, and server setting, and
if nothing is set will continue to use the old [ns_info
hostname].
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Changing the behavior of [ns_info hostname] is a bad idea.
[ns_info hostname] returns what the system's hostname(1)
command returns. The sysadmin controls that value. Making
[ns_info hostname] return something other than the system
hostname(1) value will break lots of things that assume they
return the same thing.
It might be better to simply fix ns_sendmail to not rely on
[ns_info hostname] at all, and instead use a value set in
the config .tcl and fetched via ns_config inside
ns_sendmail. Perhaps passing [ns_info hostname] as the
"default" argument to ns_config will preserve backwards
compatibility with older configurations, but at least this
way you can configure what HELO to send from ns_sendmail.
See the earlier followups that suggest exactly this,
defining a "maildomain" config parameter. Maybe "smtphelo"
would be a better choice, IMHO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sorry I must of misread the comment. I thought they
were discussing replacing [ns_info hostname] with something
that returns fqdn (perhaps ns_info fqdn).
We shouldn't be changing the functionality of ns_info
hostname, just the logic it getting the fqdn.
Personally I setup maildomain use a simple check in a
personal tcl file to make sure it is set or override
ns_sendmail not to work.
Perhaps a check in sendmail.tcl to see if maildomain (or
smtphelo, whatever) is set. If it is not set, do not allow
ns_sendmail to ... well .. send mail?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The FQDN is not only needed for SMTP HELO. Other code also
needs it (like setting the FQDN in absolute http URLs). Will
you add [ns_info fqdn] then? Or is there other way to get
the FQDN easily and portably.
(Many of the uses of [ns_info hostname] in code such as
OpenACS will need to change to the FQDN, since the FQDN is
what is really needed there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=35340
By default ns_sendmail used [ns_info hostname] to get the
helo hostname. ns_info hostname uses the gethostname() to
determine the system's hostname.
There are a few ways to address the problem.
One would be a address this in documentation and the
sample-config.tcl. Instead of using set hostname [ns_info
hostname] using something like set hostname
"my.domain.name". This would be a simple fix.
Modify ns_info hostname (in info.c) to make sure a FQDN is
pulled. Probably the most difficult thing to do and the
least helpful. In general the hostname of the server
running AOLserver will be different that the displayed
hostname. While the hostname of the server might be
kermit.domain.name, the URL will be www.domain.name. With
the vary implementations for dns resolvers on various
systems that could add a level of complexity to things.
Add a ns/parameter "maildomain" to define what domain name
should be used when sending email. This would be the best
setup. ns_sendmail could be modfied to not send mail if the
value is NULL, which would be the deafult.
Logged In: YES
user_id=21885
I'd be more in favor of defining a "maildomain" parameter to
the config and then having the ns_sendmail code use
ns_config to pull it. Just my two cents on this matter.
Logged In: YES
user_id=35340
I am created a patch that makes use of the maildomain param
suggested. Only modification was the sendmail.tcl, in the
_ns_sendmail proc.
http://mek.cc:8001/sendmail.tcl.patch.txt
Logged In: YES
user_id=35340
Cleaned up the patch a bit. Instead of throwing and error
if maildomain is not set, it logs an Error. I also cleaned
up removed the string match(s) for the configuration
parameters and replaced them with string length $var < 1.
Logged In: YES
user_id=35340
actually attaching the patch this time (d'oh, what a dork!)
patch to tcl/sendmail.tcl to add maildomain parameter
Logged In: YES
user_id=332185
It might be better to make this change backwards compatible. perhaps
something like:
set fqdn [ns_config ns/parameters maildomain]
if {![string length $fqdn]} {
ns_log warning "maildomain not defined, using [ns_info hostname]"
}
Logged In: YES
user_id=332185
One more time...
set fqdn [ns_config ns/parameters maildomain]
if {![string length $fqdn]} {
set fqdn [ns_info hostname]
ns_log warning "maildomain not defined, using $fqdn"
}
Logged In: YES
user_id=35340
That change can be made, I like to use terse log file to
give people the idea that should really make the change.
Attached is the updated patch against tcl/sendmail.tcl in HEAD
update tcl/sendmail.tcl patch (revised warning in logs)
Logged In: YES
user_id=21885
I suggested something the same to Mat on the AOLserver chat,
sans the logged warning. We should just document (perhaps
in sample-config.tcl) that either ns/parameters maildomain
is used OR [ns_info hostname]. Logging the warning seems
unnecessarily noisy -- especially if you DO just want it to
use [ns_info hostname] it seems silly to have to explicitly
define ns/parameters maildomain as [ns_info hostame] just to
squelch the warning.
Logged In: YES
user_id=661593
The warning should probably point to the file sending the warning, and
include the path to the parameter. Otherwise folks are going to scratch
heads to figure out how to fix the problem.
Is the place for this in "ns/parameters"? Shouldn't each server be
allowed to have their own under "ns/server/servername", maybe falling
back to a default under "ns/parameters"?
Logged In: YES
user_id=35340
Q: Is the place for this in "ns/parameters"? Shouldn't each
server
be allowed to have their own under "ns/server/servername",
maybe falling back to a default under "ns/parameters"?
Right now all the configuration parameters for sendmail.tcl
are under ns/parameters, I think adding a new parameter and
having two different places it can be set in the
configuration file is a bit to much. Generally mail servers
that make SMTP connections only have one name they use when
issuing the HELO command. One place for the parameters is
the best way to go.
Modifying the warning to point to the file (sendmail.tcl)
and the parameter to change should probably been done at
start up, but I think adding the configuration change to the
documentation will be enough to get the information out.
Logged In: YES
user_id=332185
I think Tom brings up a bigger topic for discussion, which is whether or not
ns_sendmail should be virtual server aware. I'd suggest applying the first
patch as is, and then taking on virtual server support as a new task.
tcl/sendmail.tcl patch to provide control for setting host used in HELO command
Logged In: YES
user_id=35340
I took the suggested into account and create the following:
Added paramater for ns_sendmail helohost
ns_sendmail to from subject body ?extraheaders? ?bcc? ?helohost?
When ns_sendmail is called, it will check if helohost is
sent, if not it will set hello host to ns_config
"ns/server/[ns_info server]" maildomain and call _ns_sendmail.
_ns_sendmail will if helohost is null. If null it will
check for ns/parameters maildomain, if still null it will
use [ns_info hostname].
This will allow people to set helohost in their coding, if
they choose, setup a global default, and server setting, and
if nothing is set will continue to use the old [ns_info
hostname].
Logged In: YES
user_id=60347
So, It is OK if [ns_info hostname] is modified so it returns
the FQDN?
Please tell us if you think is a good idea so we can close
this bug.
Logged In: YES
user_id=35340
> So, It is OK if [ns_info hostname] is modified so it returns
the FQDN?
I see no problem with it.
Logged In: YES
user_id=21885
Changing the behavior of [ns_info hostname] is a bad idea.
[ns_info hostname] returns what the system's hostname(1)
command returns. The sysadmin controls that value. Making
[ns_info hostname] return something other than the system
hostname(1) value will break lots of things that assume they
return the same thing.
It might be better to simply fix ns_sendmail to not rely on
[ns_info hostname] at all, and instead use a value set in
the config .tcl and fetched via ns_config inside
ns_sendmail. Perhaps passing [ns_info hostname] as the
"default" argument to ns_config will preserve backwards
compatibility with older configurations, but at least this
way you can configure what HELO to send from ns_sendmail.
See the earlier followups that suggest exactly this,
defining a "maildomain" config parameter. Maybe "smtphelo"
would be a better choice, IMHO.
Logged In: YES
user_id=35340
I am sorry I must of misread the comment. I thought they
were discussing replacing [ns_info hostname] with something
that returns fqdn (perhaps ns_info fqdn).
We shouldn't be changing the functionality of ns_info
hostname, just the logic it getting the fqdn.
Personally I setup maildomain use a simple check in a
personal tcl file to make sure it is set or override
ns_sendmail not to work.
Perhaps a check in sendmail.tcl to see if maildomain (or
smtphelo, whatever) is set. If it is not set, do not allow
ns_sendmail to ... well .. send mail?
Logged In: YES
user_id=60347
The FQDN is not only needed for SMTP HELO. Other code also
needs it (like setting the FQDN in absolute http URLs). Will
you add [ns_info fqdn] then? Or is there other way to get
the FQDN easily and portably.
(Many of the uses of [ns_info hostname] in code such as
OpenACS will need to change to the FQDN, since the FQDN is
what is really needed there.