Re: bug with the Message-ID ?

[Brian Stafford <brian stafford uklinux net>]

On Mon,  3 December 18:06 Peter Rexigel wrote:
> Sorry: yes I initialized this discussion ;-)
> 
> I use compuserve.de as my ISP and wanted to use balsa as my emai-client.
> 
> My summary of the whole turnaround:
> 
> 1. It is NOT possible to use balsa (btw.: also KDE's kmail)  writing
> emails.

As long as CIS do not block access to port 25 on the internet, you can either 
use a free mailbox account, such as Yahoo, for submission or you can use the 
local MTA installed along with your linux distro to submit mail.  In the 
latter case, connect to localhost:25 or localhost:587.  Your local MTA will 
resolve the recipient MX records and deliver the messages directly to the 
correct destination. A yahoo or other freemail account might be the better 
choice because the message is transferred once only when there are multiple 
recipients at different domains.

Since you mention KDE, its worth making the point that almost no Un*x MUA 
could submit via CIS, or any other standards compliant UA for that matter.

I also note that nobody has bothered to establish whether access to port 25 on 
the internet is actually blocked by CIS or not.

> 2. The reason for this is that compuserve does not accept the field
> Message   	   -ID in the email-header.

I suspect there's more to it than just this.  Anyway, whoever decided that 
message-id is a basis to block a message didn't understand what they were 
doing.

This illustrates why standards compliance is so important.  Somebody makes a 
stupid decision over a seemingly trivial header and suddenly things break.  
The problem is not everything breaks for everybody.  Instead of everything 
working as it should, everyone is hassled.  The finger of blame is pointed in 
the wrong direction.  Organisations waste their time on pointless support.  
etc etc...

>  3. There is no chance that this will be solved because CIS is not
> compatible     with the RFC 2822 standard.

Correct.  The SMTP server doesn't even provide the correct responses to 
commands.

> 4. The only solution might be that CIS would change their handling of
> emails     that confirm with the RFC 2822 standard (probably no hope).

Presumably they either want to live in a goldfish bowl in which case yes.  
Alternatively they want to participate in the global community.  If so, they 
have to conform.

> My suggestion:
> 
> WHY is it not declared in the README (or something else), that users of
> compuserve as their ISP cannot use BALSA as their email-client for
> sending emails?

Because this is not necessarily true.  Lets establish that the freemail or 
local MTA solution is unworkable first.  I suggested these yesterday but noone 
followed it up seriously.  I'm suggesting it again now.

> Without such a hint you must be persistent or you will
> throw it away with disappointment.

This is why correct information is vital.  It would be a disservice to others 
to state that Balsa does not work when CIS is the ISP, especially if the local 
MTA solution is workable - most linux distros install sendmail or postfix, 
both of which have the functionality you need more or less out of the box.

--
BCS