Troy Wical wrote:
> On Sun, June 7, 2009 9:04 am, W B Hacker wrote:
>
>> Check your on-box docs for the Exim installed. They probably point you to
>> a
>> Debian+Exim site and support list. That place will have more specific
>> information that doesn't often show up here on the 'generic' Exim list.
>>
>
> Ok, a little more progress....I think. I did go back to the debian
> readme's etc to figure out it's little dependencies and after reading it
> again, it's becoming a little clearer.
>
>> Your output should not look *quite* like that - we are using
>> tls_on_connect on
>> 587 - (akin to SSLv3 - different set-up handshakes than TLS).
>>
>> But you get the idea - your implementation has not turned-on the
>> 'submission'
>> port at 587 *at all*.
>
> The output I get in /var/log/exim4/mainlog now when restarting exim is:
>
> 2009-06-08 07:12:40 exim 4.69 daemon started: pid=29891, -q30m, listening
> for SMTP on port 25 (IPv6 and IPv4) and for SMTPS on port 587 (IPv6 and
> IPv4) port 465 (IPv6 and IPv4)
>
> 465 is in there since I am supporting MS Outlook users *sigh*
>
> Here is how I got it going based on my debian install. I know there is a
> debian specific list, but in an effort to provide followup to the existing
> thread for future users, I'll toss it in here.
>
> 1. Add the following to /etc/default/exim4
> SMTPLISTENEROPTIONS='-oX 587:465:25 -oP /var/run/exim4/exim.pid'
>
> 2. I created /etc/exim4/conf.d/main/000_localmacros , based on the
> readme's, and have the following in there at this point:
>
> smtp_enforce_sync = false
> tls_on_connect_ports=465:587
I (did) at one time do this also - but it isn't actually correct any longer.
Port 465 was reassigend to a Cisco proprietary use several years ago, so it
would be a good idea to try to move away from using it, and instead configure
the MUA's to use 587
Outlook - even fairly old Outlook *can* do a TLS connection (as opposed to
legacy 'SSL' AKA tls_on_connect on 587.
So you can list 587 in daemon_smtp_ports, but NOT list it in tls_on_connect.
Then configure the MUA to use 'TLS' and verify that port 587 selects and/or
manually change it to 587.
> MAIN_TLS_ENABLE = true
>
> Once I got the additional ports online, I started getting the following
> error, so I added the smtp_enforce_sync line:
> 2009-06-08 06:42:18 SMTP protocol synchronization error (input sent
> without waiting for greeting): rejected connection from H=[32.175.198.119]
> input="\026\003\001"
>
If you have set 'smtp_enforce_sync'= false', then that could be a zombot
operating *way* outside the protocol.
Setting to to 'true' is the tougher enforcement scenario - but you haven't done
that, so I believe that was an arrival you would have found unwanted anyway..
> After that, I started getting the error
> 2009-06-08 07:14:31 TLS error on connection from [32.175.198.119]
> (gnutls_handshake): A TLS packet with unexpected length was received.
> I changed my device (iPhone) to use port 587 but it was using "MDF
> Challenge-Responce." I changed that to "Password" and now no longer get
> the error. However, since this last change to "Password" the phone no
> longer presents the error "Unable to send mail." It just goes through the
> connection process and leaves the mail in the outbox.
>
'outbox' meaning in the MUA? What do Exim's logs show for that point in time?
> The following error continues to occur each time I try and send
> 2009-06-08 07:14:38 no IP address found for host
> mobile-032-175-198-119.mycingular.net (during SMTP connection from
> [32.175.198.119])
> I know this was talked about early on and Bill mentioned the following:
> "- NOT ENFORCE forward/reverse lookup on port 587, where your own user base
> attaches to submit mail. These will almost always be coming from a LAN,
> dial-up,
> *dsl broadband, hence will almost NEVER have a valid PTR RR or match
> forward/reverse lookup."
>
> I've not found the proper syntax to add to an acl to prevent this, yet.
>
The easy one is to make use of the fact that Exim knows which *port* the
connection arrived on (also knows if an encrypted protocol was used).
Put a condition into the acl that seeks to do the lokup such that it exemptsyour
arriving userbase MUA clients. One way is:
# CONNECT_1: Temporarily pass our own arriving MUA's.
#
accept
condition = ${if eq{$interface_port}{587}}
log_message = C1 $sender_address with $received_protocol on port 587
endpass
I don't check for PTR RR or fowrard/reverse lookup pass until two acl's later.
CAVEATS: The 'endpass' will skip all following acl logic within the
acl-smtp_connect phase, going straight into the next phase.
If you want to do more testing in the connect phase, EVEN FOR your own arrivals,
you can omit that 'endpass' and place the port 587 test in each following clause
instead - THEN use an 'endpass' to skip the rest.
Also possible to set a flag or value into an acl_c variable, then test that.
Also have a care as to what comes first if you use an IP-based blacklist or
whitelist in the connect phase.
Once the caller has had the opportunity to actually DO the login:pwd, you will
want to add. or shift to, a different test - whether they are actually
'authenticated' or not, not just which port they walked in through.
> In the end, the original scenario still stands, though I think I've made
> "some" progress.
Good progress - and your understanding is growing...
>
> Any additional thoughts?
As above. First comes good. Then comes fast.
>
> Of course, thanks again for the help.
>
> Peace, Troy
>
>
>
Igualmente,
Bill
