Mailing List Archive

On Thu, 13 Jun 2002, Peter N Lewis wrote:

> I wonder if this should be made a compatibility switch, disallowing
> them by default? The reason is, in my (admittedly naive)

given that breaking backwards compatibility very badly is not usually
a habit of Philip, i think by default it should be made to allow by
default. if there would be such an option at all, that is :)


--
[-]

On 13 June 2002, Peter N Lewis said:
> I'll add a deny in myself:
>
> deny local_parts = ^[.]
>
> Alternatively to making it a configuration option akin to
> percent_hack_domains, adding the line above (or like) to the default
> configuration might not be a bad idea?

I'm agnostic. Whatever.

> BTW, the pattern ^\. did not
> work (it denied everything) - should it?

Escaping problem. Easiest way to write regexes in Exim 4 is:

deny local_parts = \N^\.\N

Alternately, add backslashes until it works. I can never remember the
rules, which presumably is why Philip added \N in Exim 4. ;-)

Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org

> > I wonder if this should be made a compatibility switch, disallowing
>> them by default?
>
>Well, it could be, but I feel its one of those things that 99.999% of
>admins would just ignore.

Yeah, I guess that was the issue - if the admin's ignore it and if it
then tries to deliver mail to some random .file which might be a
large binary file for instance, it could compromise the system.

Anyway, just a thought. I'll leave it to your discretion.

Thanks,
Peter.

--
<http://www.interarchy.com/> <http://download.interarchy.com/>

On Thu, 13 Jun 2002, Greg Ward wrote:

> Alternately, add backslashes until it works. I can never remember the
> rules, which presumably is why Philip added \N in Exim 4. ;-)

Absolutely. People kept asking me and I kept having to spent ages
working through cases... It's quicker to be able to say "\N is your
friend".


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

On Thu, 13 Jun 2002, Peter N Lewis wrote:

> Yeah, I guess that was the issue - if the admin's ignore it and if it
> then tries to deliver mail to some random .file which might be a
> large binary file for instance, it could compromise the system.

Eh? Why would it try to deliver to a random .file? Surely you configure
Exim to check the local part before letting it deliver?


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

At 9:58 +0100 14/6/02, Philip Hazel wrote:

> > Yeah, I guess that was the issue - if the admin's ignore it and if it
>> then tries to deliver mail to some random .file which might be a
>> large binary file for instance, it could compromise the system.
>
>Eh? Why would it try to deliver to a random .file? Surely you configure
>Exim to check the local part before letting it deliver?

Exactly, I check the local part with:

require_files /Users/exim/exim/lists/$local_part

or perhaps

${if exists {/Users/exim/exim/lists/$local_part} ...

And so .DS_Store now looks like a good local part, and therein lies
the problem - for me anyway. Easily fixed, but potentially tricky.
Peter.
--
<http://www.interarchy.com/> <http://download.interarchy.com/>

On Fri, 14 Jun 2002, Peter N Lewis wrote:

> Exactly, I check the local part with:
>
> require_files /Users/exim/exim/lists/$local_part

Well, that is fairly unusual, though I now see that it might be less
rare than I thought in connection with mailing lists. Though in those
cases, the delivery normally _reads_ the file rather than writing to it.

Easy enough to block local parts starting with . in the ACL. What do
other people think? Should I make this change to the default
configuration?


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

On Fri, Jun 14, 2002 at 12:00:21PM +0100, Philip Hazel wrote:
> Easy enough to block local parts starting with . in the ACL. What do
> other people think? Should I make this change to the default
> configuration?

I'd love to see this, personally. The number of systems that don't
understand about the standard's existence, or for whatever reason
believe that they are exempt from the standard is something that,
IMHO, should be curbed. If we're all talking the same language, and
there is a specification for that language, our communication will
work much better if there isn't an encouragement to deviate from
that language.

However, I suspect I'm in a minority of one with this viewpoint.

It does seem sensible to restrict "^\..*" due to traditional mappings
of email addresses to files on disk, and the traditions of dotfiles,
which are "hidden" from a normal list, and contain configuration or
preference information.

MBM

--
Matthew Byng-Maddick <mbm@colondot.net> http://colondot.net/

On Fri, 2002-06-14 at 12:11, Matthew Byng-Maddick wrote:
> It does seem sensible to restrict "^\..*" due to traditional mappings
> of email addresses to files on disk, and the traditions of dotfiles,
> which are "hidden" from a normal list, and contain configuration or
> preference information.

I'd go further than that - in general I'd expect local_parts to match
^[a-zA-Z0-9][a-zA-Z0-9+:._-]*$

ie leading alphanumeric, followed by alphanumerics and a few special
characters. Definitely avoiding things like /\ shell meta chars etc.

Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ]
[. - Comments in this message are my own and not ITO opinion/policy - ]

On Fri, Jun 14, 2002 at 12:20:38PM +0100, Nigel Metheringham wrote:
> On Fri, 2002-06-14 at 12:11, Matthew Byng-Maddick wrote:
> > It does seem sensible to restrict "^\..*" due to traditional mappings
> > of email addresses to files on disk, and the traditions of dotfiles,
> > which are "hidden" from a normal list, and contain configuration or
> > preference information.
> I'd go further than that - in general I'd expect local_parts to match
> ^[a-zA-Z0-9][a-zA-Z0-9+:._-]*$
> ie leading alphanumeric, followed by alphanumerics and a few special
> characters. Definitely avoiding things like /\ shell meta chars etc.

interesting you should say this, because on one machine I maintain, where
I use a combination of qmail and ezmlm (best not to ask... :-), I've been
having problems with Hotmai Lusers and Yahoo! Users being unable to read,
and Hotmail and Yahoo! unable to work out what a "local-part" in an email
address actually looks like. The problem is that ezmlm, by default, uses
confirmation addresses of the form:
<listname>-<blurb>-<target local-part>=<target domain-part>@<list domain>
----------------------------------

Of course, the bit that hotmail/yahoo interpret as an email address (and
therefore turn into a link) in their webmail is as marked above. Not
hugely useful, obviously. I'd agree with you about shell metachars,
though people being unaware can make life very difficult for software
that exists already. I'm actually surprised that hotmail and yahoo are
so broken, and I'm going to be using an `_' instead, for the bits I need,
but it does illustrate the problem with making your regex too restrictive.

In general, though, I'd probably agree, and if I hadn't been battling with
this problem in the recent past, I probably would have agreed to restrict
the default down as far as you. (though, of course, `:' isn't a valid
local-part character, because it's a list begin character)

We have standards so they can be broken?

MBM

--
Matthew Byng-Maddick <mbm@colondot.net> http://colondot.net/

At 12:20 +0100 Nigel Metheringham wrote:

>On Fri, 2002-06-14 at 12:11, Matthew Byng-Maddick wrote:
>> It does seem sensible to restrict "^\..*" due to traditional mappings
>> of email addresses to files on disk, and the traditions of dotfiles,
>> which are "hidden" from a normal list, and contain configuration or
>> preference information.
>
>I'd go further than that - in general I'd expect local_parts to match
> ^[a-zA-Z0-9][a-zA-Z0-9+:._-]*$
>
>ie leading alphanumeric, followed by alphanumerics and a few special
>characters. Definitely avoiding things like /\ shell meta chars etc.

..but I chose "/" do delimit my local_part suffixes because it was OK by
the RFCs, but unlikely to be found anywhere in my department :-/

Subsequently I've needed to add the rewrite rule:

# allow "--" instead of "/" for dumb web forms that don't know RFC 2822
^(.+)\-\-(.+)@REAL_DOMAIN $1/$2@REAL_DOMAIN Tbct

..which, although ugly, Works For Me.

Matt (beware of the pathologist)

On 14 Jun 2002, Nigel Metheringham wrote:

> I'd go further than that - in general I'd expect local_parts to match
> ^[a-zA-Z0-9][a-zA-Z0-9+:._-]*$
>
> ie leading alphanumeric, followed by alphanumerics and a few special
> characters. Definitely avoiding things like /\ shell meta chars etc.

I'm happy to add "begins with ." to the default prohibitions, but I
don't think I want to go further than that.

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

Imho, iff a leading dot in a local part is defined as illegal by the
relevant RFC(s), then it would make sense to include a check against it
in the default configuration. Unless there is some terribly good reason
to not do so... for example, a significant performance hit, or if there
are many legitimate users in the world currently depending on this
particular violation of the standards.

More generally, I would vote for rigorous enforcement of existing
standards, except in cases of extreme need If you do add it to the
default config, please post the ACL mods to the list, so those of us
already configured can do it the same way.

Jim Roberts
Punster Productions, Inc.
(a very happy Exim user)

----- Original Message -----
From: "Philip Hazel" <ph10@cus.cam.ac.uk>
To: "Peter N Lewis" <peter@stairways.com.au>
Cc: <exim-users@exim.org>
Sent: Friday, June 14, 2002 7:00 AM
Subject: Re: [Exim] Dots in local parts


On Fri, 14 Jun 2002, Peter N Lewis wrote:

> Exactly, I check the local part with:
>
> require_files /Users/exim/exim/lists/$local_part

Well, that is fairly unusual, though I now see that it might be less
rare than I thought in connection with mailing lists. Though in those
cases, the delivery normally _reads_ the file rather than writing to it.

Easy enough to block local parts starting with . in the ACL. What do
other people think? Should I make this change to the default
configuration?


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

On Fri, 14 Jun 2002, James P. Roberts wrote:

> More generally, I would vote for rigorous enforcement of existing
> standards, except in cases of extreme need If you do add it to the
> default config, please post the ACL mods to the list, so those of us
> already configured can do it the same way.

The problem with "rigorous enforcement of existing standards" is
backward compatibility. ("My boss is really mad because this used to
work with Sendmail (or the previous release of Exim or whatever) - what
can I do?"). You may recall I had to relax the hard stance on
underscores in host names that I introduced in Exim 4.

This all goes back to the early Internet philosophy of "be liberal in
what you accept". This is often touted as a virtue. Personally, I think
it was a bad mistake. Once some usage gets widespread, the community is
stuck with it, whatever the standards say.

The MTA writer has four choices:

1. Insist on following the standard, period.
2. Ignore the standard, period.
3. Make it configurable, default to follow the standard.
4. Make it configurable, default to ignore the standard.

The problem with 3 and 4 is that it's a bit more code, and a bit more
documentation, adding to the maintenance effort. For some things,
however, I have taken that route. Choosing the default is a matter of
taste.

For some other things I have chosen 1 or 2. A typical example is the use
of dots in the "phrase" part of addresses. For example, this header line:

To: Dr P. Hazel <ph10@some.where.com>

is illegal according to RFC 2822 (dot is a special character). The
correct form is

To: "Dr P. Hazel" <ph10@some.where.com>

However, it is extremely common for the quotes to be omitted. I suspect
this has been going on for more than a decade. Consequently, Exim does
not enforce this rule.

Empty components in local parts is a similar kind of thing.

Fortunately, in Exim 4, it is easy for people to add their own rules if
they want to enforce the standards more rigorously, or lock out forms of
local part for other reasons.

To lock out local parts starting with dot, you just need to change

deny local_parts = ^.*[@%!/|]

to

deny local_parts = ^.*[@%!/|] : ^\\.

(But of course, ACLs apply only to SMTP input.)



--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

>> More generally, I would vote for rigorous enforcement of existing
>> standards, except in cases of extreme need If you do add it to the
>> default config, please post the ACL mods to the list, so those of us
>> already configured can do it the same way.
>
>The problem with "rigorous enforcement of existing standards" is
>backward compatibility. ("My boss is really mad because this used to
>work with Sendmail (or the previous release of Exim or whatever) -
>what can I do?"). You may recall I had to relax the hard stance on
>underscores in host names that I introduced in Exim 4.
>
>This all goes back to the early Internet philosophy of "be liberal in
>what you accept". This is often touted as a virtue. Personally, I think
>it was a bad mistake. Once some usage gets widespread, the community
>is stuck with it, whatever the standards say.

Well, I have no argument with what you are saying. If it were my boss
getting upset, I would certainly place the issue in the "extreme need"
category! ;)

I would go a bit further, and suggest that the issue of "backwards
compatibility with common usage" should be taken into account by
contributors to RFCs. Then, perhaps, strict adherence to new standards
wouldn't trigger so many such issues? And life would be easier for
programmers and administrators everywhere. (Although harder for the
standards writers, no doubt).

And, for the record, I am also for World Peace, Eradicating Hunger, and
100% Environmentally Friendly Technology. "And some pot in every
chicken!" (or something like that)... ;)

Jim

Somebody asked that I post the change to the default ACL if I added a
block for local parts starting with a dot. Here is the revised line:

deny local_parts = ^.*[@%!/|] : ^\\.

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

----- Original Message -----
From: "Philip Hazel" <ph10@cus.cam.ac.uk>
Cc: <exim-users@exim.org>
Sent: Thursday, June 27, 2002 11:10 AM
Subject: Re: [Exim] Dots in local parts


Somebody asked that I post the change to the default ACL if I added a
block for local parts starting with a dot. Here is the revised line:

deny local_parts = ^.*[@%!/|] : ^\\.

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.


Thank you, Philip.

Jim Roberts
Punster Productions, Inc.