Add "Received:" header to email msg in correct position?

[Grant Edwards]

It doesn't to me. As far as I can see what he wants to do can be done
by a mail program like procmail in combination with some mail
filtering/processing.

Does procmail implement the server-side of SMTP?

 

[Burak Arslan]

51:15 +0000, Grant Edwards wrote:

I'm working on a Python app that receives an e-mail message via SMTP,
does some trivial processing on it, and forwards it to another SMTP
server.

I'd like to do the polite thing and add a "Received:" header, but I
can't figure out how to get Python's email module to add it in the
correct place. It always ends up at the "bottom" of the headers below
From: To: etc. It's supposed to go at the above all the Received:
headers that where there when I received it.
Is this required or just being polite?
what I mean is does the standard state the headers must be in a
particular order or can they appear anywhere, you may be spending time
trying to resolve an issue that does not need fixing.
Yes, it's required. RFC 2821 [1] section 3.8.2 says "prepend".

The rationale for "prepend" is to make it possible for MTAs to add
their "Received:" headers to messages without having to parse them.

So you're supposed to do the same: Just write your Received header,
followed by '\r\n', followed by the rest of the message to the socket
and you should be fine.

I need to check and manipulate other headers for other reasons, so I'm
using the email module for that. In order to keep things consistent
and easy to understand, I'd like to use the email module to prepend
the Received header as well. That keeps my application from having to
have any knowledge about e-mail message formatting.

Seeing how discussion is still going on about this, I'd like to state
once more what I said above in other words: You just need to do this:

"Received: blah\r\n" + message.to_string()

or better:

socket.write("Received: blah\r\n")
socket.write(message.to_string())

And again, this is not a hack, this is how it's supposed to work.

Burak

 

[Chris Angelico]

Seeing how discussion is still going on about this, I'd like to state
once more what I said above in other words: You just need to do this:

"Received: blah\r\n" + message.to_string()

or better:

socket.write("Received: blah\r\n")
socket.write(message.to_string())

And again, this is not a hack, this is how it's supposed to work.

Yes, that method does work... if you're taking it in and sending it
right out again. But it means you have to hang onto two pieces of data
- the message and the new Received header - until you write it to a
file/socket.

(By the way, side point: I tend to avoid calling a socket "socket", as
that's the name of the module. I'd use "sock" in examples. Otherwise
someone's liable to go digging for a top-level method "write" in the
"socket" module, and get confused. And then think that sockets are
confusing, which they're not!)

ChrisA

 

[Ian Kelly]

Yes, that method does work... if you're taking it in and sending it
right out again. But it means you have to hang onto two pieces of data
- the message and the new Received header - until you write it to a
file/socket.

Alternatively, you could use a BytesIO to prepend the Received header to
the raw data *before* you parse it with the email module.

 

[Antoon Pardon]

Why not?

Nevermind, I originally hadn't thought things completly through.

 

[Grant Edwards]

Alternatively, you could use a BytesIO to prepend the Received header to
the raw data *before* you parse it with the email module.

That's probably what I ought to do. But subclassing Message and adding
a prepend_header was just too easy, and it avoids having to have my
app know anything about the format of an email message in general or a
header in particular. For example, I don't know what characters (if
any) need to be escaped or specially encoded in the contents of a
header. I also don't remember off the top of my head what you're
supposed to do with headers that get too long (I think you just stick
in a \r\n followed by some whitespace and then continue the header,
but I'd have to look that up and then test it).

I did know how to insert a tuple of two strings at the beginning of a
list.

 

[Ethan Furman]

Yow! All this time I've at been VIEWING a RUSSIAN MIDGET SODOMIZE a HOUSECAT!

Some filtering of your sigs would be appreciated.

 

[Chris Angelico]

I also don't remember off the top of my head what you're
supposed to do with headers that get too long (I think you just stick
in a \r\n followed by some whitespace and then continue the header,
but I'd have to look that up and then test it).

That would be correct, fwiw.

ChrisA

 

[Skip Montanaro]

Some filtering of your sigs would be appreciated.

Looks like a Zippy the Pinhead quote to me...

http://rosinstrument.com/cgi-bin/fortune.pl/21?97

Skip

 

[Grant Edwards]

Looks like a Zippy the Pinhead quote to me...

http://rosinstrument.com/cgi-bin/fortune.pl/21?97

Yep. I've removed a few of them from the file over the years because
some people were offended by them. And I'll continue to do so...

 

[Tim Chase]

Yep.

I'm kinda disappointed having the curtain pulled back like that. I'd
just assumed it was some nifty tool that turned a GPG/PGP signature
into MadLibsâ„¢-style fill-in-the-blank and then flowed into various
templates, allowing Grant to confirm/deny message authorship based on
the unspoofability of the signature with any other message-body.

Sounds like a fun weekend project ;-)

-tkc

 

[Ethan Furman]

Yep. I've removed a few of them from the file over the years because
some people were offended by them. And I'll continue to do so...

Thanks, much appreciated.

 

[Grant Edwards]

I'm kinda disappointed having the curtain pulled back like that. I'd
just assumed it was some nifty tool that turned a GPG/PGP signature
into MadLibsâ„¢-style fill-in-the-blank and then flowed into various
templates, allowing Grant to confirm/deny message authorship based on
the unspoofability of the signature with any other message-body.

That would be cool...