Re: bug with the Message-ID ?

[Brian Stafford <brian stafford uklinux net>]

On Mon,  3 December 12:04 M. Thielker wrote:
> Hi,
> 
> On 2001.12.03 09:52 Brian Stafford wrote:
>> I think this is wrong, RFC 2822 requires messages to have Message-Id:  It 
>> might be better if the identity specified  the domain to use when 
>> generating the message-id: header instead.
> 
> No, CIS will not accept a message with _any_ message id, AFAIK.

This blatantly violates RFC 2822 which requires the presence of the header.

> They go to great lengths to insure that only subscribers use their service 
> and to foil any attempts, even by subscribers, to use mass mailing software.

That much is reasonable.

> Since such software typically inserts a forged message id,

How can a message ID be forged?  Its just a globally unique identifier - an 
opaque token at that.  The only reason the use of the host name is recommended 
is to disambiguate identifiers generated on different hosts.

> from and possibly received headers,

Examining the sender and recipient fields on submission makes *much* more 
sense.  Most ISPs do this nowadays and are permitted to do so by RFC 2476.

> the CIS mail server will reject any such messages. CIS's is a very old 
> system that between '85 and '98 was accessible with proprietary software 
> only, in some areas, by preference in others.
> They still go on the assumption that the user uses their WinCim software, 
> even though they have started to adopt some internet standards.
> No one will be able to show them the error of their ways because their 
> ultimate answer will always be "Use our software, ItWorks!"

In which case, why bother with standards at all?

> Now, we can either stick to the requirement that all systems Balsa can 
> connect to _must_ strictly adhere to the standards or we can adapt to the 
> actual conditions, that most systems don't implement the standards 
> completely, or do additional things in violation of existing standards.

Melanie, I know this thank you - after all, I have written a SMTP client that 
works very reliably, not a trivial task given the insane MTA configurations 
there are out there.  However, allowing users to configure their way out of 
standards compliance is a Bad Thing.  E-Mail is such a mission critical 
application that standards compliance is rather more important than with most 
other protocols.  Before venturing down this path, things must be very 
carefully considered.

> I would opt for adding an option to sippress the message id completely, not 
> based on any checks or the port number ...

Umm, to suggest that the relay/submission issue is decided by port number is 
to misunderstand RRC 2476.  RFC 2476 permits the use of port 25 for submission 
so long as the MTA is not publicly referenced.  A publicly referenced server 
listens to the internet on port 25 *and* is referenced by an MX record.  
Ultimately the distinction is made by the server, not the client.

> ... but with a simple checkbox on prefs.

Well since such an option allows non-compliance to be selected, I don't think 
it should exist in the UI, even if a configuration variable is created to 
suppress message id.

> Most systems currently in use will use port 25 for submission as well as 
> forwarding and will distinguish between the two by the recipients address.

Maybe so, but this is unreliable.  Sendmail is famous for doing the wrong 
thing because of this.  BTW I knew that too.  Sendmail's authors know it too - 
current versions implement submission on 587.

> Some, like CIS, will not accept a message id if the transaction is deemed to 
> be a submission.

I'll say it again - this is just plain wrong.

> Forcing Balsa to use a port other than 25 for this to work will only serve

What's all this stuff about ports anyway?  Port 587 is the default for 
submission, 25 is the default for relay, but that's all they are - defaults.

> to limit Balsa's usability because a corporation as big as CIS _will_ not 
> change the way their server works just because _one_ program requires it.

I seriously doubt Balsa is the only MUA that provides message id on submitted 
messages.


Please don't have a go at me because I try to make my software strictly adhere 
to standards.  A few users may suffer but the vast majority will benefit 
because RFC 2821/2822 and 2476 have been designed for maximum interoperability 
with the existing deployed SMTP infrastructure.  Conforming rigorously to 
these is a pretty good guarantee that everything works as expected.  I have 
been involved on the ietf fax WG and followed much of the exchanges on drums.  
I am aware of the complex and subtle issues and controversy with mail 
transport enough to know that the authors of RFC 2821/2822 and 2476 have been 
very careful in the specification of those documents.  Who am I to undermine 
their work?

As soon as the ability to incrementally flout standards is introduced, people 
will start messing around with the options to do so.  Most likely they will 
stop something working that would have worked anyway had it been left alone.  
Eventually, there will be some combination that works for one server but not 
another.  Then I get flamed for being unable to write working software (and I 
have had some quite abusive messages sent to me from people who don't know 
what they are talking about).  As it is I'm fairly pissed off because people 
can't be arsed to read the SMTP server information in balsa's README and 
help.  Bottom line - once I am sure that submission is standards compliant, 
then and only then will I consider breaking compliance for special cases - and 
even that will need a very powerful case before I am prepared to do it.  I 
take this attitude because I am trying to make things easy for users, not 
because I want to be dogmatic.

In particular, if there is *any* workaround for non compliant servers, I will 
not change code "for convenicence", that will be inconvenient for many.  In 
this case, assuming compuserve does not block access to port 25 on the 
internet, why not run a local MTA and submit via that?

I really do get the impression that people think I just read some standards 
and worte libESMTP with no real world experience of mail transport - nothing 
could be further from the truth.  I hope I'm wrong about this because I really 
do find that attitude quite offensive and insulting.

--
Brian Stafford