mail-ng
[Top] [All Lists]

Re: What I see as problems to solve ... and a strawman solution

2004-01-30 10:39:25

At 10:35 30/01/2004, Kai Henningsen wrote:

I don't have problems with most of your requirements & suggestions, but..

2. Define an XML format for headers and envelopes. No non-XML sub-encoding
- every piece of information and structure must be basic XML. There's
enough there so other tricks just aren't necessary. (And namespaces seem
of doubtful use in this context.) This also allows for defining better
semantics for headers, as appropriate. Oh, and inside this thing, charset
MUST be UTF-8 period.

No. I don't like XML when it's not needed.
I would see this as overcomplicating. Personally I don't have much of a problem with header formats, envelopes, and header/body separation at the moment.
I'd go along with UTF-8 character set
I'd also simplify the header by eliminating header line wrapping. This is a minor thing, but could solve some parsing issues. Nowadays, there's really no reason to have artificially short fixed length line limits, so why have header line wrapping.

The header: data structure in the header and the blank line separating header and message content is pretty straight forward to parse and is unambiguous.

Oh, and get rid of . padding - just specify the accurate message length using another means.

* every sending MTA *must* have at least one certificate, and this
certificate MUST be interrogated by the receiving MTA and noted into a
trace header. Possibly even demand TLS-only, but I'm less convinced of
that.
* those certs really should be verifyable by the receiver - possibly via
something in DNS; definitively not by following the browser model and
effectively forcing every cert to be signed by a very few agencies like
Verisign.

No, don't have certificates. They either need to be signed by a few agencies or they can be easily forged. They also add complexity.

Simply have some sort of callback. Eg I get a connection from someone claiming to be 'mail.aol.com'. I do a DNS lookup and see that 'mail.aol.com' really does resolve to the IP address of the person who's talking to me. I think that's enough really. It's pretty hard to fake, and gives traceability.

* The submission MTA really ought to also sign the non-envelope part, as
in "this is how the mail originated here". (The above business MTA would
then be modeled as a re-submission.) Or maybe it signs a checksum while
creating the first trace entry. This first trace entry should record where
the mail came from, but need not do so in a format third parties can
understand so long as the local admin can.

I'm not sure what signing the message achieves apart from added complexity, that couldn't be achieved in other ways. I don't think people in general are worried about emails being modified during transmission, they're worried about spam and viruses. So, all that people would want from this signing is some 'provable' identifier of the original mail server.


Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                     http://www.pscs.co.uk/