Re: Different SMTP-Servers for different Identitys

[Brian Stafford <brian stafford uklinux net>]

On 2003.08.05 22:18, Pawel Salek wrote:
> 
> On 2003.08.05 02:09, Andreas Köhler wrote:
>> hi,
>> 
>> i just want to support this feature request, because at the moment 
>> i  have to change the smtp server settings ca. every five emails i  
>> write. i read somewhere in the archives that this feature is not  
>> important and nobody needs it. there are at least two people on 
>> earth  really hoping that somebody with extra time would investigate 
>> into  that issue.
>> 
>> if there is somebody that has this time and can code and i would 
>> like  to help out a bit, so that this gets implemented in the near 
>> future.
> 
> Out of mere curiosity: I thought that SMTP AUTH extension was 
> supposed  to resolve this kind of problems. Isn't it working 
> correctly? Or just  not deployed widely?

SMTP AUTH works OK, it's a straight down the line implementation of RFC 
2554 with the extension of supporting the non-standard AUTH= hack for 
those ISPs and MTA authors who don't see fit to stick to standards.  
Deployment is certainly on the increase but by no means universal 
although problems with open relays and spam are forcing this issue.

A number of problems might occur though.  First the LOGIN 
authentication mechanism is not in any RFC.  It did exist in an 
internet draft at one time but that is no longer available.  As a 
result no gurarntees can be made about its correctness as it is not 
possible to determine what actually is correct.  Another one might be 
that the server offers only authentication mechanisms for which no 
libESMTP plugin exists.

Typically when submitting mail without AUTH, the message is accepted 
only if the mailbox named in the MAIL FROM: command is a valid account 
with the operating ISP.  Some configurations go further and check that 
the From: header is the same as the MAIL FROM: mailbox but this is a 
bad idea as mailboxes in the message headers are unrelated to those in 
the SMTP envelope, e.g. when the message sender is not the author, in 
resent messages or list traffic.  There has been discussion on this 
topic on the list in the past.

In my experience when AUTH is used the MSA will accept pretty much 
anything in the MAIL FROM: command as the sender has already been 
authenticated.  However, there is nothing stopping additional checks on 
the SMTP envelope and message headers even when authenticated.  IIRC 
this is the first report of such a problem to date - at least that 
hasn't been resolved by using SMTP AUTH.

I did once consider what would be required to implement multiple SMTP 
servers in balsa and decided that the effort was too great compared to 
the benefit that might be achieved.  Two implementations come to mind, 
in both cases the SMTP server and its associated authentication 
information is associated with the identity.  It should be possible to 
fall back to the default SMTP server if one is not defined in the 
identity however.

The first approach would be to have a separate outbox for each 
identity.  Messages are placed in the outbox associated with the 
identity.  Then when submitting messages each outbox is transmitted to 
the associated SMTP server.  Since libESMTP is thread safe all 
mailboxes could be processed in parallel in threaded balsa.

The alternative is to associate metadata with each message in a single 
outbox.  The metadata would contain at least the identity to use for 
each message.  As the outbox is processed, a libESMTP smtp_session is 
created for each identity encountered and on completion all 
smtp_sessions are transmitted.  I feel that the metadata is best stored 
in a gdbm or tdb file rather in message pseudo-headers.  Managing 
headers in libmutt seems somewhat complex (and inefficient for large 
mbox files).

In the latter implementation, the metadata could easily be extended to 
contain the SMTP envelope data.  This would dramatically improve 
certain aspects of the message submission process such as 
retransmission of partially failed messages, i.e. when some recipients 
experience 4xx temporary failure responses the metadata could be 
updated to flag recipients which have suceeded or permanently failed 
and therefore do not require resubmission.  This is an area where balsa 
is currently weak.

A potential downside of this might be that it would make maintaining 
the option of using sendmail (puke) to submit messages more difficult.  
However my opinion is that, despite unix tradition, using sendmail 
commands to submit mail has no place in a modern networked environment 
and support for it should be removed.

Brian