Re: [exim] virtual domains, incorrect envelope-from

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] virtual domains, incorrect envelope-from
Seth Dillingham wrote:
> Exim is happily handling mail for a number of virtual domains with
> non-login accounts, both incoming and outgoing.
>
> However, all mail sent by our users through our server ends up with a
> bad Envelope-From address.
>
> Here's an example from a message I just sent:
>
> Received: from xxx.ri.ri.cox.net ([y.y.y.y] helo=Sprung-Sprocket.local)
>     by zzz.macrobyte.net with esmtpsa (TLSv1:AES128-SHA:128)
>     (Exim 4.72)
>     (envelope-from<"seth@???>)
>     id LB7Q4I-000MMQ-4X
>     for seth.dillingham@???; Mon, 01 Nov 2010 11:38:42 -0400

>
> The correct address, of course, is just "seth@???".
>
> I've seen some mail rejections, though it's not clear if they're being
> caused by these strange Envelope addresses.
>
> All relaying requires smtp authentication via either PLAIN, LOGIN, or CRAM-MD5.
>
> In the MUA, the users set their smtp user id as "user@???" (so
> in my case, it's "seth@???").
>
> Using sg, i extract the host name from the user id, and find that
> domain's password file. The passwords within that file are of keyed on
> only the local part of the user name.
>
> My guess is that I've caused the bogus Envelope-From addresses by
> using the full email address as the smtp auth user name.
>


Pros and cons to that. But it is not required. Our login UID's are free-form,
can even be in Chinese - or anything PostgreSQL/UTF-8 can deal with...

And SQL is not the only way to do that..

> What's the right way to do this?
>
> Thanks for any guidance...
>
> Seth
>


Exim has general-purpose settings for keeping on-box / cross-box addresses
within specified parameters - especially if/as/when a member of your user-pool
(or a script), has not done (or CANNOT do) the expected..

Look at 'qualify...', 'local..' and relatives w/r both $local_part and $domain.

CAVEAT: AFAIK, the legacy common use was for shell submission, and 'presumed'
primary_domain ELSE a forced over-ride.

But DB/file lookups work also, so you probably need the same sort of lookups as
you do when vetting the login.

...Which, BTW, you can simply store and re-use IF (and ONLY IF) it is ALWAYS the
(proper) email@<correct domain>.<correct tld>.

HTH,

Bill