On 2/13/2017 11:10 AM, Mike Brudenell via Exim-users wrote:
> Hi, Phillip -
>
> On 13 February 2017 at 17:44, Phillip Carroll <
> postmaster@???> wrote:
>
>> Some questions:
>> Should my mta deny RCPT from any host that did not send a MAIL verb? Is
>> that sequence even permitted by RFC? Even if not RFC-permitted, is it
>> fairly common practice (other than by bad actors)? Should I repeat all the
>> MAIL tests in the RCPT ACL, or simply move all the tests to the RCPT ACL?
>> It appears that the sample conf file avoids this issue by having no MAIL
>> time checking at all. However, checking at MAIL time avoids redundant
>> conversations with DNS and ZEN in the case of multiple recipients. Seemed
>> to me the logical place for it.
>>
>
> Have you tried using Telnet to connect to port 25 on your mail server and
> seeing whether it accepts a RCPT TO without a previous MAIL FROM? I ask
> because I've just done that here with my test server and Exim rejects the
> RCPT TO, complaining no sender has been given yet:
>
> % telnet tmailgw 25
> Trying 144.32.129.129...
> Connected to tmailgw.york.ac.uk.
> Escape character is '^]'.
> 220 tmailgw.york.ac.uk ESMTP Exim 4.86_2 Ubuntu Mon, 13 Feb 2017 17:57:05
> +0000
> helo testmachine
> 250 tmailgw.york.ac.uk Hello tardis.york.ac.uk [144.32.226.226]
> rcpt to: test@???
> 503 sender not yet given
>
>
> I've not put any special tests tests into Exim's configuration file to
> implement this, so believe it to be Exim's standard behaviour. If your
> server is permitting it then you might have accidentally/deliberately put
> something into your configuration to cause it.
>
> As for the RFC, you can find RFC 5321 Simple Mail Transfer Protocol at
>
> https://tools.ietf.org/html/rfc5321
>
>
> Section *3.3 Mail Transactions* states:
>
> If a RCPT command appears without a previous MAIL command, the server MUST
> return a 503 "Bad sequence of commands" response.
>
>
> To debug you might want to run up a test server and run Exim in daemon mode
> with debugging options turned on. For example, to go mad and turn
> everything on:
>
> exim -v -d+all -bd
>
>
> (I'm sure you can select fewer options to the "-d" option if you wish!)
>
> Then fake up an SMTP session to that server to mimic the problem you're
> seeing, and after entering each SMTP command look through the debugging
> output to trace through what tests and actions your configuration file is
> causing.
>
> Cheers,
> Mike B-)
>
Mike,
Thanks much for the highly detailed reply.
I guess it would be easy to try a simple test to prove that exim will
reject a RCPT verb without a preceding MAIL verb; but then I guess there
would be no point to it because you have already proved that it will.
A Telnet test of the config without modifying it would pose a lot more
difficulty. (Reverse DNS lookups, etc.) The amount of work and expense
seems overkill.
It would seem to be a tad easier on my part to deduce the part of my
config that isn't working correctly.
I will start with the following:
The "accept" commands in the mail acl that precede the helo/host match
test were accompanied by logwrite commands that specify the reason for
the accept. The only other accept in the RCPT acl is unconditional.
However, I stupidly failed to put a logwrite on that final accept, which
would easily have proved that the MAIL acl was or was not run prior to
RCPT. I have now corrected that oversight by adding a logwrite to that
accept.
So let's assume that the MAIL acl was run for the offending email. In
that case it had to have passed my match test. Although I thought that
test was working---as evidenced by entries in the reject log---the only
reasonable logical deduction is that it sometimes fails to catch mismatches.
The test I thought was working is:
deny message =\
helo/host mismatch\
helo=$sender_helo_name\
host=$sender_host_name
condition = ${if eq \
{${extract{-1}{.}{$sender_host_name}}}\
{${extract{-1}{.}{$sender_helo_name}}}\
{no} {yes}}
condition = ${if eq \
{${extract{-2}{.}{$sender_host_name}}}\
{${extract{-2}{.}{$sender_helo_name}}}\
{no} {yes}}
# continuations were inserted here for readability.
# The message and each condition are on single lines in the conf.
Hopefully, somebody here can point out a flaw in my conditions that fail
to detect some non-matches. Or even show me a simpler way to test the
same thing.
Phil
