Re: [exim] Rejecting non-RFC compliant email addresses?

Pàgina inicial
Delete this message
Reply to this message
Autor: Gregg Berkholtz
Data:  
CC: exim-users
Assumpte: Re: [exim] Rejecting non-RFC compliant email addresses?
On Wed, Jun 08, 2005 at 11:32:56PM +0100, Matthew Newton wrote:
> On Wed, Jun 08, 2005 at 02:16:26PM -0700, Gregg Berkholtz wrote:
> > I've begun receiving emails with quotes or slashes in the
> > recipient's address, and my exim daemon/config (v3.35) is accepting
> > the addresses as valid - to a point... My understanding was that
> > such characters, within email addresses, should not be treated as
> > valid.
>
> What makes you think that? As far as I am aware, pretty much anything
> is allowed in the local part. Technically certain things are not OK if
> they are unquoted (for example two .s next to each other). Quoting the
> local part should be used in this case. i.e. .test@??? is not
> technically correct, but ".test"@??? is OK. Similarly,
> "hello/world"@??? should be fine.
>

I was basing my assumption on the information at
http://www.remote.org/jochen/mail/info/chars.html - plus a grain of
salt... In any event, this is an environment where I cannot forsee a need
to use quotes or slashes in an address, so, considering the LDAP lookup
error we're getting, we're inclined to reject such "envelope to"
addresses outright. Unless of-course something could be done about the
LDAP lookup error.

> Obviously the same does not hold for the domain part, which follows
> normal DNS rules.
>
> Others please correct me if I am wrong.
>
> We have the following in our exim RCPT ACL:
>
>   deny    local_parts = ^.*[@%!/|] : ^\\.

>
> It might be what you need (or similar).
>
> Hmmm... just noticed you are using exim 3.35. Not sure this will work
> there. Sorry, you're probably on your own, as it's totally out of date
> and most people seem to have forgotten how to configure it now.
>

Yes, very old, and no ACL support AFIK... Though version 3.35 is what
comes with Debian 3.0. With Debian 3.1 (Exim 4.50) just being pushed to
stable, we're planning for an upgrade, though it's a major upgrade which
is still a luxury for a few more months...

> HTH,
>

Something to work with in a few months... Thanks.

Gregg Berkholtz