smtplib needs me to put from/to headers in the message?

T

Tobiah

Thank you for the valuable clarification, and the pointers.
I will look into the RFC's. I wonder though, whether that
will solve my main question, which is why the python.org
example mandates that I specify 'from' and 'to' twice.

Thanks,

Tobiah

Ben said:
In the example at:
http://docs.python.org/lib/SMTP-example.html

The text of the email message ends up with the From: and To: headers
in it, and yet the call to sendmail() on the server object requires
me to specify them again.


[Pet hate issue: Every RFC 2822 email message has exactly *one* body
and *one* header.
 
T

Tobiah

Thank you for the valuable clarification, and the pointers.
I will look into the RFC's. I wonder though, whether that
will solve my main question, which is why the python.org
example mandates that I specify 'from' and 'to' twice.

Thanks,

Tobiah

Ben said:
In the example at:
http://docs.python.org/lib/SMTP-example.html

The text of the email message ends up with the From: and To: headers
in it, and yet the call to sendmail() on the server object requires
me to specify them again.


[Pet hate issue: Every RFC 2822 email message has exactly *one* body
and *one* header.
 
T

tobiah

In the example at:

http://docs.python.org/lib/SMTP-example.html

The text of the email message ends up with the From:
and To: headers in it, and yet the call to sendmail()
on the server object requires me to specify them again.

Shouldn't smptlib just make the headers for me, given
the 'from' and 'to' addresses? Perhaps this allows
me to spoof the 'from' address. Still, I might as well
just make all of the headers myself, and pass the message
as a single argument to sendmail().

Or perhaps I'm missing it altogether.

Thanks,

Tobiah
 
B

Ben Finney

tobiah said:
In the example at:
http://docs.python.org/lib/SMTP-example.html

The text of the email message ends up with the From: and To: headers
in it, and yet the call to sendmail() on the server object requires
me to specify them again.

[Pet hate issue: Every RFC 2822 email message has exactly *one* body
and *one* header. The header contains multiple fields. Most library
terminology, including the 'smtplib' and 'email' modules, gets this
wrong.]

The smtplib does no processing or parsing of the message data,
correct. You should have the from and to addresses parameterised, use
the 'email' module to create the message and 'smtplib' to send it:

<URL:http://docs.python.org/lib/module-email.html>
<URL:http://docs.python.org/lib/node597.html>
 
D

Dennis Lee Bieber

Thank you for the valuable clarification, and the pointers.
I will look into the RFC's. I wonder though, whether that
will solve my main question, which is why the python.org
example mandates that I specify 'from' and 'to' twice.
"From:" and "To:" serve, if you will, as "inside address" of a snail
mail.

The "from" and "to" parameters to are the addresses on the actual
envelope. There is no requirement that they be the same...

Though it might be useful to extend the library with an optional
parameter that specifies "parse message for addresses to use"...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
T

Tim Roberts

tobiah said:
In the example at:

http://docs.python.org/lib/SMTP-example.html

The text of the email message ends up with the From:
and To: headers in it, and yet the call to sendmail()
on the server object requires me to specify them again.

Shouldn't smptlib just make the headers for me, given
the 'from' and 'to' addresses?

No, it shouldn't.
Perhaps this allows
me to spoof the 'from' address. Still, I might as well
just make all of the headers myself, and pass the message
as a single argument to sendmail().

E-mail consists of two distict and separate standard. The standard for how
e-mail is exchanged between systems is SMTP, in RFC 2821 (originally 821).
The standard for the format of a message, including headers and body, is in
RFC 2822 (originally 822).

SMTP needs to know who is sending, and where it going. That's what the
first two parameters to smtplib.sendmail provide. The entire contents of
the e-mail message, including the headers and the body, are completely
opaque to SMTP. The message is nothing but "data".

That's why you need to specify it twice. The first two parameters are for
SMTP, and are used by the mail server (e.g., sendmail). That part is
called the "envelope". The body is only used by the mail reader at the
other end, which never sees the data in the SMTP exchange.

Further, the SMTP protocol doesn't care about To:, Cc:, and Bcc:. There is
just a list of addresses. To: and Cc: are just for the convenience of the
person reading at the other end.

If it didn't work that way, you couldn't do Bcc:'s. When you use a Bcc: in
your mail program, the name gets added to the SmTP

This is how a Bcc: is done. A Bcc: header is never included in an e-mail
message. The address gets included in the envelope, but not in the headers
or body.
 
C

Carl J. Van Arsdall

Dennis said:
Though it might be useful to extend the library with an optional
parameter that specifies "parse message for addresses to use"...

I actually agree with this, not to say that it wouldn't be difficult to
write that function, but I think it would be a definite nicety.

I've always thought that the best way to do it would be to construct the
message in its entirety, this would include to, from, etc. Then
whatever smtp library is available simply takes that message and a
server and handles the rest. I don't think that the current
functionality should be stripped out or anything, but that this other
"interface" exist for a much more intuitive emailing system.

-carl



--

Carl J. Van Arsdall
(e-mail address removed)
Build and Release
MontaVista Software
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,436
Messages
2,571,696
Members
48,796
Latest member
Greg L.
Top