Re: Insert signature patch

[Brian Stafford <brian stafford uklinux net>]

On Tue, 15 May 23:08 Carlos Morgado wrote:
| On Tue, May 15, 2001 at 10:36:35PM +0200, Pawel Salek wrote:
| > 
| > On 2001.05.15 18:03 Brian Stafford wrote:
| > > | balsa-1.1.5 really soon(TM) (within couple of days). It would be
| good
| > > | to update the documentation, in particular help/C/balsa.sgml and
| > > | README files to describe recent changes.
| > > 
| > > Someday I'll document how libESMTP uses the "host[:port]" syntax.
| > > I promise :-)
| > 
| > Well, I have impression that the basic syntax is simple, but the
| > port values and defaults are not quite obvious for everybody...
| > 

True.  What is less obvious is that I allow the port to be a name
from /etc/services also.  So "host.example.org:smtp" would work.

However among things I have in mind for the future is to adopt
URI syntax say "smtp://user:pass@host.example.org:25/".  The only
reason I haven't done it this way is that I can't find an RFC describing
this, though I vaguely remember seeing an Internet Draft on this once.

Another thought I had was to allow pine's trick of specifying
a list of fallback servers,
e.g. "host1.example.org, host2.example.org ..."

Finally, there is another way to start a service ... the way inetd
does using fork/exec and running the protocol across a pipe or
AF_LOCAL socket. Sendmail operates this way with the -bs option
running an SMTP session on its standard input.  This type of operation
might have its place in libESMTP (if I do this I might add support
for te LMTP protocol too).  A syntax to allow this might look like
"|/usr/sbin/sendmail -bs".

I think I need to write a concise explanation for application authors
to cut and paste into their documentation to make it easy for them
to keep up to date as this evolves.

| I forgot to mention (my bad) i changed the default on the config
| wizard to localhost:25. I figure someone who has clue enough to
| use the new port has clue enough to configure it. Objections ?

Fair comment, I agree.

| Brian: what if libesmtp tried port 25 as fall back when it can't
| connect to the specified *if* the specified port is 587?
| it's not very Right, but sounds practical :)

I'd need to give this long and hard thought.  The reason 587 has
been assigned as a mail submission port is that the semantics at
the server are allowed to be different.  According to RFC 821
an MTA is only allowed to add the Received: header at the start
of the message.  So sendmail's habit of rewriting addresses in
headers, adding missing Message-ID:/Date: ... headers has never
been standard, at least not since 1982.  This sort of thing has
been known to damage messages in transit.

On 587 the MTA is free to mess around with headers, add digital
signatures, corporate disclaimers ... whatever.  As 587 is
adopted, it becomes easy for an MTA to identify message submission
from messages in transit and allows non-standard behaviour to be
eliminated from port 25 SMTP.

Another reason for the distinction is that it makes authentication
and firewalling *much* easier to administer.

Right now, I don't think there would be much harm in having the
fallback behaviour. However, as 587 is adopted for message submission
and 25 only adds a Received: header, very different behaviour
can result on each port even if the same server is listening on
both ports.  Right now, I feel this makes the fallback algorithm
broken behaviour and thus should not be implemented by libESMTP.

| should the muas themselfs do this ? any (strong) opinion?

Other than the problem outlined above, the only issue here is that it
might interact badly with libESMTP's semantics for the server name,
especially if I extend the syntax.

However something along the lines of
	...
	smtp_set_server (session, "localhost:587");
	if (!smtp_start_session (session)
		&& smtp_errno () == -ECONNREFUSED) {
		smtp_set_server (session, "localhost:25");
		smtp_start_session (session);
	}
	...
should work OK assuming identical server semantics on both ports.
I guess if done, this should be #ifdef'ed and a configure option added
to select the fallback behaviour.

I suspect the best solution for now is decent documentation.

Regards
Brian Stafford