Re: Setting the stage

I must admit, I'm having quite a hard time coming up with things that I'd 
want in 'mail-ng', that I couldn't do with the current protocols and some 
extensions..
Now, it is an argument that all the extensions make SMTP etc unwieldy and 
hard to use, but any protocol that is going to be a core part of the 
Internet has to be extensible or it's pretty much going to die. So, if all 
that 'mail-ng' does is to make many of the extensions of SMTP redundant and 
then start having its own extensions, I think serious thought needs to be 
done before obsoleting such a widely deployed protocol as SMTP.
That doesn't mean that I don't think a 'mail-ng' could be a good thing, 
just that I think that many of the suggestions at the moment could be done 
using SMTP extensions.
Maybe even some SMTP extensions could be made SMTP mandatory items. Eg if 
people want to get rid of C-T-E, then why not make 8Bit transport mandatory 
in SMTPV2. OK, you'll need a gateway system to allow SMTPV2 to work with 
servers that don't upgrade from SMTPV1, but you'll need that anyway for 
mail-ng to work with servers that stick with SMTP.
So, you could probably come up with a 'desirable' extension set to SMTP 
that meets lots of peoples requirements, and then define a new TCP/IP port 
number, new DNS RR record and have gateways. This would allow people to 
make 'SMTPV2' servers without having to start from scratch. In this case 
things like 8 bit transport would actually be easier as one of the reasons 
people may not implement it is that they have to worry about converting 
back to 7 bit for the onward server - if you know the onward server 
supports 8 bit data, then lots more people would do it.
---

OK, now I've said that maybe 'SMTPV2' is the way to go rather than 
'mail-ng', I'll try to come up with a few things that couldn't be done 
without major modifications to SMTP - which would make it less SMTP-ish 
than most current extensions do.
- I would like to get rid of anonymity. I agree with Eric Hall that there 
are ways of having 'anonymity' which I'd be happy with. All I want to know 
is that the person who sent an email was allowed to use that sender's email 
address. I don't care if the email address is 
'g438dgsdj43y(_at_)anonymousremailer(_dot_)com', as long as I know that the sender had 
been given permission by anonymousremailer.com to use that address. In that 
case, if I get lots of spam from anonymousremailer.com and complaints don't 
achieve anything, I can ban mail from that domain to my server.
- I would like to be able to know that if I get an email with an address 
'fred(_at_)aol(_dot_)com' it has come from an AOL email server. This is related to the 
point above, but is subtly different. I know a lot of people like the 
current ability with SMTP to be able to use a different email server to 
send mail from their main email address, and who would oppose this (when 
suggestions to implement a similar thing in SMTP have been proposed there 
has been strong opposition from some people), but with proper 
authentication you could use your 'home' mail server to send your outgoing 
mail, so this wouldn't be a problem.  (Sorry, this could actually be done 
quite easily in SMTP, so it could be in SMTPV2, not in mail-ng)
- I would like my mail server to be able to look at a message 
structure/headers/etc before being given the message. Sort of like the 
IMAP4 'fetch' command, but on incoming SMTP-type mail connection (eg I get 
a connection saying 'I've got mail for you', I can then respond and say 
'Has it got any attachments, what are they?' before deciding to collect it)
- I would like to consider the possibility of having mail stored on the 
SENDERs mail server. Eg, if someone sends me a message, I get sent a "URL" 
which I can use to view/retrieve the message (not in a web browser - 
although maybe that would be an thought..). This would make it easier to 
have 'file sharing' without having to transmit the file to everyone. I'm 
not convinced this would be a good idea, but I think it's worth thinking about.
- I would like enforced track-ability of emails. Eg, I send a message, I 
want to be able to know if it has arrived at the other end. I would 
actually like to be able to go back (within a time frame, eg 1 week) and 
ask my mail server 'what happened to <such and such> an email'. That mail 
server could then look at its records and say, 'I sent it to <xyz> mail 
server', and then go and ask 'xyz' mail server, 'what happened to <such and 
such> an email that I sent you <whenever>', and so on until the SENDER can 
get a trace of what happened to the message, if it got bounced somewhere, 
where that was, if it got discarded somewhere etc
- I would like to see stricter conformance to standards enforced from the 
beginning. With SMTP & current message formats we have a situation where 
lots of MTAs/MUAs will try to interpret an incorrectly formatted message, 
where other MTAs/MUAs will just not bother (which is OK, IMHO). This can 
cause interoperability problems. I'd like to have the standards say 
'incorrectly formatted messages/headers/envelope/etc should be rejected'. 
This would make everyone do things properly (or they'd notice quickly 
because EVERY other program they tested it with would reject it), and make 
testing easier etc.
- Personally, I would like to get rid of being able to send inline images, 
complex HTML etc in an email... I'm happy with "normal" attachments, I 
could accept a bold/italic/underline/link etc formatting, but I don't want 
tables, javascript, DHTML etc in an email... I'd say stop allowing HTML 
messages at all, and have a basic email formatting style which is formatted 
differently
Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                     http://www.pscs.co.uk/