On Wed, May 15, 2002 at 05:25:17PM +0200, Andreas Henriksson wrote:
 
| I have problem sending mail to some email-addresses (some MTA's), I'll
| start with describing my situation:
| 
| I'm connected to the Internet via NAT. I have no access to the servers
| that have a "real" Internet address, and the chances I can get the
| admins to change anything is close to zero.
| 
| I use mutt to send email.. so I need a local MTA to deliver the mail.
| (This is where I differ from the rest of the users on the network,
| since regular MUAs have built in SMTP capabilities.)

You're situation is no different except for the software you are
using.  Whether exim is doing SMTP or whether MS Outhouse is, it's
still SMTP and will work or fail similarly (except that exim has much
better error handling and reporting!).

| I've tried different configurations without luck... here I'll describe
| what happens when I configure exim with the eximconfig-tool in debian
| choosing "Internet site with smarthost".
|
| Here is an example of the Received part of the header
[snipped Received: header showing localhost]

| Now to the problem....
| 
| I've noticed that some servers traces the servers mentioned in Received
| (for example "telia.com" does), and then they bounce mail when they find 
| MTA-addresses they can't resolve. 

Who does this?  RFC (2)821 explicitly state that the Received: headers
have no standard format and are not to be used except by mail admins
in tracing a problem.

| Is there any way I can get exim to use a smarthost and "hide" itself so
| I get a similar Received path as MUA's under windows produce. (I mean..
| MUAs that has built in SMTP capabilities so they can use remote MTAs.)

MUAs like that suck because they don't add a Received: header and thus
make tracing problems harder.  RFC821 says that a Received header is
to be added precisely for tracing messages to debug systems.  Given
that you need/want to deal with systems that are making life hard for
you, I'll help you out :-).

Edit /etc/exim/exim.conf.  Find the line that looks something like :

# the timestamp is automatically added on at the end, preceded by a semicolon.
received_header_text = "Received: \
         ${if def:sender_rcvhost {from ${sender_rcvhost}\n\t}\
         {${if def:sender_ident {from ${sender_ident} }}\
         ${if def:sender_helo_name {(helo=${sender_helo_name})\n\t}}}}\
         by ${primary_hostname} \
         (Exim ${version_number} #${compile_number} (Debian))\
         \n\tprotocol: ${received_protocol}\n\t\
         id ${message_id}\
         ${if def:received_for {\n\tfor <$received_for>}}\n\t"


Change this to something like :

received_header_text = "Received: \
         (Exim ${version_number})\
         \n\tprotocol: ${received_protocol}\n\t\
         id ${message_id}\n\t"


Basically I just removed the ${primary_hostname} part, which is where
your host's name is inserted.  As long as we're trying to make the
header rather useless (qmail also has _really_ useless headers) I
stripped out the other information relating to hosts and the
connection.

| I've also tried sSMTP which I read was good for "dialup-users". This 
| MTA also applied the local host as the first (or last, depending how 
| you look on it) received element.

Yep, it behvaes too! :-)

| So it didn't help me.... (and then I would have to find a substitute
| for fetchmail since sSMTP can't do local deliveries).

No, you shouldn't have fetchmail trying to do SMTP anyways.  It is not
a full-fledge MTA and won't properly follow the rules for error
handling (queueing and retrying, etc).  Use the 'mda' option in your
.fetchmailrc instead :


poll <host> protocol <proto>
    user <user> , password "<pass>"
    is <localname> here 
    options stripcr , mda "/usr/sbin/exim %T" 

HTH,
-D

-- 

The heart is deceitful above all things
    and beyond cure.
    Who can understand it?

I the Lord search the heart
    and examine the mind,
to reward a man according to his conduct,
    according to what his deeds deserve.

        Jeremiah 17:9-10
 
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg

Attachment: pgpTkaRNZCvQs.pgp
Description: PGP signature

Reply via email to