I think you missed what I was trying to get at… You’re using your
internal servers for your users to connect to, and send mail, right?
Yet, you have your internal server try to relay through the QMT server.
Since that server is requiring authentication, the QMT server is
rejecting it.
Why not have your internal server deliver your user mail directly to the
remote mail server, not relaying it through your QMT servers.
IE, instead of:
YOURINTERNALSERVER -> YOURQMT -> REMOTESERVER
why not:
YOURINTERNALSERVER -> REMOTE SERVER
If you remove the info in smtrproutes, the server should deliver the
mail directly to the destination server by using MX record information,
which should work, and there should be no log entry in the QMT servers
logs. If there is, then your internal server is still trying to send
all mail via the QMT.. Make sure you’ve restarted qmail, you might even
try rebooting to make sure it’s reloaded the correct smtproutes info.
**Michael J. Colvin**
**NorCal Internet Services**
**//www.norcalisp.com// <http://www.norcalisp.com/>**
<http://www.norcalisp.com/>
------------------------------------------------------------------------
*From:* [email protected] [mailto:[email protected]]
*Sent:* Tuesday, November 10, 2009 2:17 PM
*To:* [email protected]
*Subject:* Re: [qmailtoaster] eMPF requires authentication to work?
Michael,
good question. I hate this answer, "because that's the way its always
been". :) Actually, I tried removing the contents of
/var/qmail/control/smtproutes on the internal server and restarted
qmail. I get the same darn error message in the log file on the
qmail-toaster server.
11-10 16:07:45 CHKUSER accepted rcpt: from <[email protected]::>
<mailto:[email protected]::> remote
<inet.local.solution-group.com:unknown:192.168.105.110> rcpt <aci
[email protected] <mailto:[email protected]>> : found existing
recipient
11-10 16:07:45 policy_check: local [email protected]
<mailto:[email protected]> -> local [email protected]
<mailto:[email protected]> (UNAUTHENTICATED SENDER)
11-10 16:07:45 spamdyke[27917]: DENIED_OTHER from: [email protected]
<mailto:[email protected]> to: [email protected]
<mailto:[email protected]> origin_ip: 192.168.105.110 origin_rdns:
(unknown) auth: (unknown)
And in the logfile of the internal server, it looks like everything went
fine.
@400000004af9e452316418ac new msg 33916470
@400000004af9e4523164b8d4 info msg 33916470: bytes 1346 from <> qp 20677
uid 10040
@400000004af9e452318befe4 starting delivery 6: msg 33916470 to remote
[email protected] <mailto:[email protected]>
@400000004af9e452318c518c status: local 0/10 remote 1/20
@400000004af9e452380fd844 delivery 6: success:
207.224.111.118_accepted_message./Remote_host_said:_250_ok_1257890865_qp_27923/
@400000004af9e452380fe3fc status: local 0/10 remote 0/20
@400000004af9e452380febcc end msg 33916470
My eMPF policy file on the qmail-toaster server does not restrict any
accounts with ending in solution-group.com.
Strange.
Dave
Michael Colvin wrote:
Why not have the internal server deliver the mail itself? Is there a
particular reason you need to relay through the QMT servers?
Michael J. Colvin
NorCal Internet Services
www.norcalisp.com <http://www.norcalisp.com>
-----Original Message-----
From: [email protected] <mailto:[email protected]> [mailto:[email protected]]
Sent: Tuesday, November 10, 2009 11:42 AM
To: [email protected]
<mailto:[email protected]>
Subject: [qmailtoaster] eMPF requires authentication to work?
Hello list,
I have been using eMPF for about one year now and it does a great job
limiting email accounts and/or who they can send or receive emails
from. Thanks for including it in the distribution.
I have noticed that eMPF requires that the user sending the email
authenticates (otherwise how would it know if the user was allowed to
send or not). I run several applications (nagios, timetrex, etc) on
servers I have on my LAN. These internal servers occasionally send
automated emails. I have qmail (from source boo!) installed on the
internal servers, but not qmailtoaster. I have the internal servers
relay mail to my qmailtoaster server. I entered the ip address of the
qmailtoaster server into /var/qmail/control/smtproutes control file of
my internal servers.
If the application I am running (see above) has a config section where I
can enter a smtp server, a valid [email protected]
<mailto:[email protected]> and a valid
password, then my qmailtoaster will accept the email and relay
successfully. However, if application does not have a config section
for the smtp server, username, and password or the application uses a
phpmailer (which many do) the relayed email fails. In the smtp log file
on the qmailtoaster spamdyke reports "DENIED OTHER" which means "The
text returned by qmail (or the downstream filter that generated the
rejection).". Here is a section of the smtp logfile on the qmailtoaster
server when the email fails:
11-10 11:55:20 policy_check: local [email protected] <mailto:[email protected]> ->
local
[email protected] <mailto:[email protected]> (UNAUTHENTICATED
SENDER)
11-10 11:55:20 spamdyke[21618]: DENIED_OTHER from: [email protected]
<mailto:[email protected]> to:
[email protected] <mailto:[email protected]> origin_ip:
192.168.105.110 origin_rdns:
(unknown) auth: (unknown)
If I empty my /var/qmail/control/policy file (empf config file)
basically turning eMPF off, and send the same message, it is
successful. Here is a section of the smtp logfile on the qmail toaster
after turning off eMPF
11-10 13:26:25 policy_check: local [email protected] <mailto:[email protected]> ->
local
[email protected] <mailto:[email protected]> (UNAUTHENTICATED
SENDER)
11-10 13:26:25 spamdyke[24110]: ALLOWED from: [email protected]
<mailto:[email protected]> to:
[email protected] <mailto:[email protected]> origin_ip:
192.168.105.110 origin_rdns:
(unknown) auth: (unknown)
Does anyone know a way around this?
Turning off eMPF is not an option since my client insists on limiting
email accounts. I read a post by Eric dated 10/29/2009 regarding "a
quickie guide to configuring postfix to relay securely to a toaster".
This seems simple enough. I suppose I would need to remove qmail first
and seeing how it was installed from source, it may be a little more
complicated than "rpm -e".
Any suggestions, comments, etc. would be greatly appreciated.
Thanks,
Dave
--------------------------------------------------------------------------
-------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com <http://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: qmailtoaster-list-
[email protected] <mailto:[email protected]>
For additional commands, e-mail: qmailtoaster-list-
[email protected] <mailto:[email protected]>
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com
<http://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]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------------------
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]
