On Fri, 8 Sep 2000, Javier Ribelles wrote:
>
> Hi all, first of all, sorry for some of my poor english expresions
> you'll find in my mail, but it's been long since I last used it ;)
De nada.
> ...
>
> When I started qmail, all seemed to work fine... Mail was correctly
> delivered inside an outside the server. But I like to send mail through
> telneting port 25, so I did this:
>
> telnet localhost 25
> HELO aimplas.es
> MAIL FROM: jribelles
> RCPT TO: jribelles
> DATA
> hola
> .
> quit
>
> ...
>
> So, everything seems to be right... Now let's take a look at users' inbox
> (/var/spool/mail/jribelles) ...
>
> From jribelles Fri Sep 08 07:57:54 2000
> Return-Path: <jribelles>
> Delivered-To: [EMAIL PROTECTED]
> Received: (qmail 11831 invoked from network); 8 Sep 2000 07:57:53 -0000
> Received: from localhost (HELO aimplas.es) ([EMAIL PROTECTED])
> by localhost with SMTP; 8 Sep 2000 07:57:53 -0000
> hola
>
> Well, all I can see here is that the header is missing, fields "From", "To",
> and "Date" should appear after second "Received:" line, but they do not... Of
> course this only happens when delivering to a local user... And I have
> discovered why...
>
> Mail clients do send the header after the DATA tag, like this...
>
> ...
> DATA
> Date: Fri Sep 08 07:57:54 2000
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>
> hola
> ...
>
> This would be the DATA they would send... doing that makes it work
> fine... If you put only a "Subject" or "From" field, and you do not specify
> all the fields (or maybe only the date), it will ignore the rest of the
> message, and will show you only the fields you've entered...
The SMTP daemon (qmail's or anyone elses for that matter) is not
responsible for adding RFC822 headers such as From: or To: etc. All
the SMTP daemon does is accept the incoming data and possibly add a
Received: header.
The sending system is responsible for 'doing the right thing' with
respect to From: headers etc.
By telnetting into port 25, you were acting as the SMTP client, so you
were resonsible for adding the From: header etc.
Here's a sample from my system:
telnet allspice 25
Trying 192.168.16.20...
Connected to allspice.e-smith.net.
Escape character is '^]'.
220 e-smith.net ESMTP
helo risotto
250 e-smith.net
mail from: <[EMAIL PROTECTED]>
250 ok
rcpt to: <[EMAIL PROTECTED]>
250 ok
data
354 go ahead
From: Peter Samuel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: testing from telnet
g'day
.
250 ok 968422217 qp 27634
quit
221 e-smith.net
Connection closed by foreign host.
I gave the system the appropriate RFC822 headers, and here is what
ended up in my Maildir/
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 27634 invoked from network); 8 Sep 2000 14:09:43 -0000
Received: from unknown (HELO risotto) (192.168.16.154)
by 192.168.16.20 with SMTP; 8 Sep 2000 14:09:43 -0000
From: Peter Samuel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: testing from telnet
g'day
The bottom line is that your system is working properly. You just
assumed it was going to do more than it actually does.
>
> I tried making it work by removing completely /var/qmail (rm -Rf
> /var/qmail/*) and reinstalling qmail and fastforward and ucspi, but that
> doesn't solve the problem.. maybe it's not a qmail problem, but procmail's? But
There was no need to reinstall. It was working fine.
> I don't understand why it's happened after rebooting the system...
>
> Maybe the problem is in qmail-local or qmail-smtpd->qmail-queue, as
> doing
> echo "To: jribelles" | /var/qmail/bin/qmail-inject
> works fine...
That works fine because qmail-inject creates From: and To: headers etc
if they don't already exist. That is part of its job.
qmail-smtpd's job is not to add headers that aren't there.
--
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
http://www.e-smith.org (development) http://www.e-smith.com (corporate)
Phone: +1 613 368 4398 Fax: +1 613 564 7739
e-smith, inc. 1500-150 Metcalfe St, Ottawa, ON K2P 1P1 Canada
"If you kill all your unhappy customers, you'll only have happy ones left"
