Re: [exim] non-ascii in the envelope

On Wed, 27 Jul 2005 20:18:36 +0100 Tony Finch <dot@???> wrote:

> On Mon, 18 Jul 2005, Phil Chambers wrote:
>
> > I am seeing an increasing number of messages which contain non-ascii characters in
> > the envelope sender. I am inclined to reject them.
> >
> > 1) Is there a good reason not to reject when non-ascii characters are in the
> > envelope sender?
> >
> > 2) Would my suggested comparison be likely to produce any false psitives?
>
> Hmm, this should probably be considered a syntax error and therefore a
> protocol violation. I'm currently playing around with a patch that will
> allow you to configure strict syntax checking of MAIL and RCPT commands,
> the original reason being to forbid the use of space between : and <, but
> adding a check for non-ascii characters would seem sensible too.
>
> Tony.

That would be very helpful. I had not appreciated that no space was allowed
between : and < in MAIL and RCPT, but i see now that RFC2821 is quite clear on
it. I have always put a space in when trying a manual connection when testing
and have never had it rejected!

This illustrates an example of the old maxim of being liberal in what you
accept and strict in what you send. It is a maxim that I am now very much
opposed to. It just allows poor quality software to proliferate and the
developers responding with "well it works with everyone else" when one
complains that they are not following the rules.

Have you done any tests to see if rejecting spaces between : and < will block
many non-spam mail software and have you any idea when your patch may be
available?

In the meantime, what do you think about my suggested test of camparing
$local_part with ${rfc2047:$local_part} and rejecting if they do not match?

I have been reluctant to use it in case I have overlooked a reason why it will
not work.

Phil.
---------------------------------------
Phil Chambers (postmaster@???)
University of Exeter