dzoey@umd5.UUCP (02/16/87)
[ Are there really sites still out there with line eater problems? ] Greetings, I have a little return path dilemma. I want to send mail (SMTP) from my PC to other sites. However, I don't know how to identify myself to other sites. Currently, I say 'HELO [my-internet-address]'. This is okay because everyone pretty much treats 'HELO <text>' as devoid of meaning anyway. The problem comes about when I want to tell the host who the mail is from. Ideally, what I'd like to do is lie and say MAIL FROM:<user@maildrop>. Maildrop is not my PC, since my pc doesn't want to spend all it's time running as a SMTP server. Maildrop is a host that is aware of the network a large percentage of the time and is the place where I read my mail (in our case, we use POP to retrieve mail from the maildrop host to our PC's and read it there, but you get the picture...) The problem is that some SMTP servers will not let you lie about who you are, and will toss the mail away if it thinks you are bogus. So, in a bit of a panic, we tried MAIL FROM<user@[inet-address]>, which is ugly. If the SMTP server wants to send me an advisory back, all it has is the PC's address. Since the PC does not run an SMTP server, it can never receive the advisory. So, periodically, the SMTP server that is trying to send an advisory keeps trying to open a connection. I don't know what it does when it can't open a connection to send an advisory, or how long it will try to do so, but this isn't the behavior I want. So, our mail guru (Hi Zben!) suggested a null return path. E.g. MAIL FROM:<>. But, some sites do not accept that as valid. We have a hacked up Sys5r2 machine upstairs that wouldn't accept that (I don't know if this is the case for all of Sys5r2, or it's just the hacks) and a site out at ucla running MVS would not accept that. Also, I'm afraid I'm going to break someones SMTP server by throwing all those domain literals around. So, what do I do? Suggestions would be greatly appreciated. Appologies for the cross posting, but I wasn't sure for which group this question was best suited. Joe Herman dzoey@terminus.umd.edu dzoey@umdd.bitnet P.S. In case it wasn't clear, the way that we have implemented it as a stop gap is to say MAIL FROM:<"Joe Herman"@[128.8.1.63]> (ick). P.P.S. This question only applies to the SMTP transaction. We are able to successfully mung the headers to do what we want, so people who want to reply to our mail generate the mail drop address. It's the out-of-band info that's a problem right now. -- "Everything is wonderful until you know something about it."
jordan@ucbarpa.Berkeley.EDU.UUCP (02/17/87)
Joe Herman <dzoey@umd5> writes:
I want to send mail (SMTP) from my PC to other sites. However,
I don't know how to identify myself to other sites. Currently,
I say 'HELO [my-internet-address]'. This is okay because
everyone pretty much treats 'HELO <text>' as devoid of meaning
anyway. The problem comes about when I want to tell the host
who the mail is from. Ideally, what I'd like to do is lie and
say MAIL FROM:<user@maildrop>. Maildrop is not my PC, since my
pc doesn't want to spend all it's time running as a SMTP
server.
I don't see the problem.
What you really want to do is the following (for example):
----- BEGIN EXAMPLE
HELO joes_pc.umd.edu
MAIL FROM:<dzoey@maildrop.umd.edu>
RCPT TO:<jordan@ucbarpa.Berkeley.EDU>
DATA
Received: by joes_pc.umd.edu id AA25297; Mon, 16 Feb 87 18:15:50 EST
From: Joe Herman <dzoey@maildrop.umd.edu>
Date: Mon, 16 Feb 87 17:50:22 EST
Message-Id: <8702170150.AA02078@joes_pc.umd.edu>
To: jordan@ucbarpa.Berkeley.EDU
Subject: Some mail for you ...
[ mumble ]
.
----- END EXAMPLE
You do in fact need to tell the truth in the HELO statement, but
are free to hack your outgoing mailer to give a different FROM
address ...
/jordan
zben@umd5.UUCP (02/18/87)
In article <17386@ucbvax.BERKELEY.EDU> jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) writes: > Joe Herman <dzoey@umd5> writes: >> I want to send mail (SMTP) from my PC to other sites. However, >> I don't know how to identify myself to other sites. ... > I don't see the problem. > What you really want to do is the following (for example): > HELO joes_pc.umd.edu > MAIL FROM:<dzoey@maildrop.umd.edu> > ... > From: Joe Herman <dzoey@maildrop.umd.edu> > You do in fact need to tell the truth in the HELO statement, but are free > to hack your outgoing mailer to give a different FROM address... For that matter he could have included a "Reply-To:" field. But you are missing the point. Internet advisories go back via the reverse-path and not via the Sender: or From: fields. A returning advisory will cause the sending mailer to continuously try to access a nonexistant SMTP server on the joes_pc node... -- umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
jordan@ucbarpa.Berkeley.EDU.UUCP (02/18/87)
Ben Cranston <zben@umd5.umd.edu> writes: But you are missing the point. Internet advisories go back via the reverse-path and not via the Sender: or From: fields. A returning advisory will cause the sending mailer to continuously try to access a nonexistant SMTP server on the joes_pc node... Um, which "reverse-path" are you talking about? Perhaps the one that I've marked below? >> HELO joes_pc.umd.edu --> >> MAIL FROM:<dzoey@maildrop.umd.edu> >> ... >> From: Joe Herman <dzoey@maildrop.umd.edu> The SMTP (note: *not* the headers in the message) command "MAIL FROM:" is what gets used for a return in case of a problem. This in fact points to a usable mailbox in my scenario. Also, in the part of the body of the message (that which follows the SMTP command "DATA") has a From: line that points to the same place so that UAs (User Agents) can use it if they like. The only place that I have mentioned joes_pc was in the SMTP command HELO, which a few recieving SMTP's are now policing. This has NOTHING to do with where to send an advisory. /jordan