[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Stripped addresses and IMAP clients



[This is being sent to the pine-info mailing list, as well as the zmailer
discussion list.  The former is gatewayed to comp.mail.pine, the latter
is mail-only.  If readers of either list by mail follow-up, both lists
should be included; however, those who read comp.mail.pine and choose to
follow-up will fail to have their comments seen by the zmailer group
unless a copy is sent to <zmailer@cs.toronto.edu> as well.  Just a warning.

    Here are the details of my setup:
Zmailer is running as MTA on the machine ccsun.tuke.sk.  I have a
mailbox there, and prefer to receive my mail there.
I access this mailbox with a client connected to the IMAP server running
on ccsun.tuke.sk.  My client, Pine, is on a different machine in a
completely different domain.

    Mail sent from Pine on ccsun receives a fully-qualified domain name
automagically, so it is handed to zmailer as <barryb@ccsun.tuke.sk>, for
example.
    Zmailer rewrites the fully-qualified sender's name, if delivery is
done locally, with only the login.  In other words, the mail in the
spool looks just like this, in part:

From:	Kamil Kukura <kamk>
To:	Kevin Mitnick <Barry.Bouwsma@tuke.sk>
Message-ID: <Pine.SUN.3.91.950313204123.6074A-100000@ccsun.tuke.sk>

    What happens is that I read this mail spool via IMAP and reply from
the host more local to me.  Here I quote from a message I sent out...

> My IMAP client gave this... To: Kamil Kukura <kamk@cap1.capaccess.org>
> 
> That's because the mail arrived in my mailbox with <kamk>...  I guess
> zmailer doesn't fully qualify names, and removes the domain from those
> delivered to the localhost.  I guess that's okay if you only read mail
> locally, but when you access it via IMAP or POP, that seems to be a
> pretty bad idea.  Is it possible for zmailer to keep fully qualified
> e-mail addresses when delivering locally,  [...]

    As Pine users know, Pine will append the domain name to any logins
to create a complete e-mail address.  But here it fails spectacularly,
as the login on the mail which has the appearance of being local, really
appeared on a different machine, with different domain name.

    Given that zmailer is delivering mail in this rather distributed
environment, my feeling is that what it should be doing (and what any
MTA should be doing), given the increased use of remote protocols such
as IMAP to read mail, is not reducing e-mail addresses to the bare
minimum, with the resulting ambiguity, but rather, the MTA should
instead always be completing incomplete e-mail addresses.  Comments?

    It is noted in the Pine tech notes that using e-mail addresses that
are not complete is a source of all sorts of problems, like this one. 
Is it possible to configure zmailer to leave e-mail addresses alone if
they arrive in full from the local machine?  Should this be the default
configuration?

    Another possibility would be for the IMAP server to complete
addresses such as this if found in a header when serving the mail to the
remote client.  How desirable is this?  (The presence of an incomplete
address saved from a client on one machine to a folder on a different
server is one case where this would fail.)

    I'm posting this to both groups to get comments from all who use
either program, even though I think that there are other mailers and
MTAs which use only a login for address, and fail to append a full
hostname to it, and the MTA also fails to append a hostname.  The
configuration of v8 sendmail here leaves <login> in the To: field, when
sent without attached hostname, so this sort of problem extends beyond
zmailer, perhaps needing attention from the IMAP server as well...
Maybe the default sendmail configuration should be to always add the
hostname to those addresses lacking one, as well...

    Comments and discussions about the best solution, or combination of
solutions, to this problem, are encouraged...


hacker Barry Bouwsma, MIME: <barryb@ccsun.tuke.sk>  ASCII: <ag786@yfn.ysu.edu>

--hACKeD-MIME-mEssAge-BouNDaRy-666--