[prev in list] [next in list] [prev in thread] [next in thread] 

List:       listar-support
Subject:    [ESupp] Old problems - Solved?
From:       W B Hacker <wbh () conducive ! org>
Date:       2006-09-24 22:37:35
Message-ID: 451708AF.9040705 () conducive ! org
[Download RAW message or body]

A while back, there was a thread on Ecartis being unable to send with qmail.

Having just worked through a similar issue with Exim, there seems to be a 
generic problem, one to whch I have a workaround, but still seek a more elegant 
solution.

Meanwhile, while fine-tuning a fix and documentation:

Background:

- Ecartis gets its MTA-agnosticism by emulating a peer MTA over (usually) 
localhost, performing the same connect, HELO/EHLO, etc. handshakes, as would any 
other MTA when submitting traffic. It does not use the 'mail', 'sendmail' etc. 
executables.

That was all well and good in times gone by when any 'entity' on-box could make 
essentially unrestricted use of the MTA w/o being considered a relay attempt.

No more!

As a result of spam that ID's as, and HELO's as, the target victim's own box, 
not to mention PHP, formmail, and other rude on-box and cgi script hacks and 
carelessness, the 'modern' MTA may - or may not - still allow use of the 'mail', 
'sendmail' (emulated), or exim <options> scripts, but more commonly with each 
passing month has several settings to prevent local-residents, or their hacked 
emulations, from utilizing the MTA, *especially* for transit to off-box 
destinations.

Symptoms:

So long as I had Ecartis 'aimed' at 'localhost', all I could see was:

~/exim/mainlog: the message arriving from the external test box, being 
handed-off to the correct router/transport set I have set up for it in Exim [1], 
reporting delivery completion.

~/ecartis/ecartis.log: all expected settings being loaded, message file being 
created and torn down in the spool, but not a peep about smtp success, failure, 
or sidegodlin'ism, module unload, and normal exit.

Per Exim, the message went into the exim pipe command, but was never 
re-submitted for outbound (remote_smtp) delivery, and none of the daemons 
bitched about that (except me!)

Once Ecartis was 'aimed' at the smtp entrance with a fqdn, eyes popped open:

~/exim/mainlog showed the messages of ecartis HELO'ing as (one of) ourselves in 
an acl that drops the connection when that happens.

~/ecartis/ecartis.log showed the steps and responses of the smtp progression, 
displaying the rude error messages Exim sends to fools who think they are us, 
showed retry activity, then wait-forever (Exim had dropped the other end - but 
WTH - we are inside the IP stack, not really over the wire...)

The BFBI fix (so far):

- going ahead and using a fqdn for Ecartis MTA 'target', but 'exempting' it from 
acl checks within Exim that would interfere with it.

*Note* that having Exim listen on 'localhost', adding OR removing the fqdn 
Ecartis was 'HELOing' as to Exim's 'relay_from_hosts' and/or 'local_domains' did 
not solve the problem.  As similar stps had not for the qmail user....

The 'elegant' fix:

As the smtp sequence is already coded-in, why not do this:

- add (restore?) the 'smtp-port' variable so as to allow pointing Ecartis at 
both an off-box MTA by fqdn/IP, AND to the submission port of same.

- provide for a username & password so Ecartis can authenticate.

Optionally provide for Ecartis to use TLS to auth and submit.

The 'silver lining' in this fix, is that it not only insures the ability to work 
as a trusted submitter to the 'local' MTA, preserving and enhancing 
MTA-agnosticism, but it should permit use of *any*  MTA that permits passing the 
traffic via the subscribed account.

With some other minor tweaking, this could further reduce the need of 
sysadmin/mailadmin help to install aliases, etc. [2]

More after I have had some sleep.... [3]

Bill Hacker

[1] tested both with the 'traditional' ~/etc/aliases pipe entries and 
~/ecartis/lists structure, AND with a modified version of a virtual-domain set 
of Exim customizations published here:

http://www.aagh.net/files/ecartis.txt

..by Thomas Hurst <freaky@aagh.net>

Where 'modified' vs his approach, will accomodate BOTH ordinary accounts AND 
lists for the same virtual domain sets.  Or not. (PostgreSQL controlled).

[2] Ultimately, our settings will be DB-resident, so rights to the DB may be 
totally unrelated to shell accounts, etc. - even set on a differnt box, then 
exported.

[3] Lest I forget, the snippet of exim code on the current Ecartis docs is a an 
obsolete, and now harmful, example of a 'director' left over from Exim 3.X days. 
Badly needs removing. Will try to re-write that section.





--
Ecartis Support Mailing List <ecartis-support@ecartis.org>
To unsubscribe:
  <mailto:ecartis-support-request@ecartis.org?Subject=unsubscribe>

[prev in list] [next in list] [prev in thread] [next in thread]