Re: [exim] replace Received From:

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Vicente
Date:  
À: exim-users
Sujet: Re: [exim] replace Received From:

thanks a lot for your lights. I will try with those predefined adjustments.

About the Law issues, I'm not any expert. However, I assume that when
I put the authentic name of my domain.com theorigin would be preserved.
I mean, when somebody use a web-client email like Squirrel or any
other, the client IP will not be present but just the server IP
sending that message. When the client IP would be saved in a server
log, it is not different of many commercial services. There are a lot
of forums and e-mail lists in where messages doesn't contain the
client IP because are re-sent by the local machine.

Then maybe I can put the authentic IP of the server as happens when an
e-mail is sent using Squirrel. Here there is not falsehood and the
access would be preserved in the server. A message can be traced
until that access and the customer would be protected of anybody in
the planet who can know where he lives.

As I told you before, I'm not an expert in these things. Do you think
this can be right in a general Law sense?

Btw, can you help me with some ideas for this replacement and the
right place to put it in exim.conf?. I'm a php programmer but not
perl. :(

I'm using exim+sendmail and spamassasin.

Comments or help would be greatly appreciated


best regards,

V


--------------
W.B wrote:

> Several.


> Three of the easiest involve little or no modification to Exim itself.


> 1) install a webmail service. There are plenty of those around, written in PHP,
> perl, python, ruby, etc. These are handy to have in any case. Pay attention to
> security.


> At least two, one in perl, another in python, are full-fledged web-resident
> MUA's - IOW can handle POP/IMAP accounts on servers other than those on which
> they reside as well as the 'local' ones (if any).


> One of these even instantiates its own bespoke https webserver, so no need for
> Apache, etc. or interfering with an httpd that is doing web pages (not always a
> good idea on a mail server anyway).


> 2) Work from an ssh shell with the Unix/Linux basic mail functions. Not as
> clumsy as it soudns if you have cut 'n paste terminla functionality.


> 3) Use a more fully-featured Unix mailer toolset, such as 'pine' or 'mutt'.
> Several folks here do so.


> In all of the above cases, you are already 'resident' on the server, so the
> adsl/dialup/<whatever> link is no longer of concern to the MTA and
> 'automagically' disappears.


> The only adjustments you *may* need to make to Exim are w/r:


> qualify_domain         =


> qualify_recipient      =


> And:


> local_sender_retain     =


> local_from_check        =


> - Depending on which of the above you elect to use, whether shell-account or
> virtual, etc. All documented.


> See if one of these makes any sense for your needs first, as - depending on
> where you operate, munging the other headers is potentially going to put you at
> odds with ToS, perhaps even the Law of the Land and such w/r 'concealing the
> origin' of email. Not to mention making troubleshooting more difficult.


> HTH,


> Bill