Thanks for taking the time to discuss this with me Dave. You probably have
a better understnding than me which helps educate me! I guess this whole
discussion is really moot as mail can easily be forged.
> -----Original Message-----
> From: Yorkshire Dave
> > I think the problem lies in that this is an optional field. Seems
> > like many people offer an interpretation to justify as to how they
> > want to use it - me included. I would at least like to see SHOST
> > in the Message-Id. I would like to see SHOST in the first
> > Received line.
>
> I'm trying to get a grip on the concept here, whereabouts in
> the received line do you want to see it? In an authoritative
> position or just anywhere like in the HELO?
There are a lot of situations/configurations that already work the way I am
describing. For example, your Message-Id and first Received lines look like
this:
Message-Id: <[EMAIL PROTECTED]>
Received: from wot.no-ip.com (chilli [IPADDR])
by netfinity.wot.no-ip.com [snip]
for <[EMAIL PROTECTED]>; Wed, 27 Aug 2003
So your Message-Id is in the form of:
Message-ID: <[EMAIL PROTECTED]>
with SHOST being chilli. chilli is also in the first received line. I
think it would be beneficial to maintain the helo as it is usually the
hostname in FQDN format. I do realize that the helo hostname can be altered
by MTAs etc. I just think it would be better to tie it to the hostname and
not change it. However, my preferences really don't matter as long as the
Message-Id can be tied to the audit trail which should be the first received
line. Has there really ever been syntax with *nix where the @ was not
followed by host (@host)? And shouldn't the first received line indicate
that the host that sent the message?
> > And I would like to see
> > hostnames configured as host.some.domain.
>
> If you always need that to be a host.domain which you can
> resolve back to the ip address of the originating machine,
> you've excluded NAT altogether. If you don't need it to
> resolve then all you're asking for is that the pile of junk
> characters have a dot in them.
I agree if you are talking about broadband users. Otherwise, NAT is dealt
with using split DNS. Again, SHOST would be fine. A lot of MTAs use
domain. Using a domain is ok but if one is going to use domain, I would
like to see host.domain.
> Oh yes I know RECOMMENDED is only a shave away from MUST, but
> the whole section is focused upon uniqueness rather than
> provision of some sort of connection audit trail. If you
> interpret it as an absolute MUST then you're saying anything
> without its own exclusive host.registered-domain MUST NOT
> generate a message-id, which seems wrong to me.
This is where I guess I am really ignorant. What good is a Message-Id? I
see the prupose of the Message-Id aiding threads so that messages can be
tied to the parent. I just don't understand why it can not also be tied to
the audit trail.
I see your point about the registered domain. Broadband/dial-up would be
hampered.
> Maybe this is why it doesn't actually say MUST, the RFC isn't
> shy about saying MUST in other places. I take RECOMMENDED to
> mean that deviating from the recommendation requires
> understanding the reason for the recommendation and trying to
> closely follow the logic behind it.
I see your point. And I understand decisions like Comcast replacing the
original Message-Id with a geographic-based Message-Id. I just don't think
it has to be that way. I also believe it strays from the intention of
uniqueness. But I guess I have no corner on what intention means.
Dave, thanks again for the discussion!
--Larry
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
