[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sieve, and header_t's api
From: |
Alain Magloire |
Subject: |
Re: sieve, and header_t's api |
Date: |
Mon, 23 Apr 2001 01:20:36 -0400 (EDT) |
> >
> > - There is no real protection in C, you just (char *) cast and
> > write to the buffer, which may change the offsets of the parsing
> > and the next header_get_value() will go to "lala" land.
>
> You can ALWAYS cast in C, but then its your fault.
>
> *((char*)message_t) = 'a'; //... ;-)
8-)
Do not why but I could not stop laughing 8-) ... it was so unexpected
as an argument. 8-)
>
> > > I guess that I can do this means that the API is ok, but it seems like
> > > such a general purpose thing, that I'd like to maybe clean it up, and
> > > sell it as an adapter to wrap around header_t.
> > >
> > > create_header_cache(header_cache_t* ch, message_t m);
> > > header_cache_get_field_values_p(header_cache_t ch, const char* name,
> > > const char*** values);
> >
> > Looks cool/interesting.
>
> Ok, hopefully I can wrap it up nicely, I'm still prototyping now.
Thinking about it why not take over of the entire object, since
header_t suppose to be a class that you can overload all the
functions/method. You should be able to "inherit" from it i.e.
polymorphism.
cache_header_create (header_t *ch, message_t m)
{
struct my_private_data *owner;
header_create (ch, owner);
// Overload the differrent methods.
// Take over _get_value
header_set_get_value (ch, owner);
// Take over _get_field_values ()
....
}
Then you got a special "header_t" that is caching the data.
hmm ... I feel that I'm missing some of your points though.
> > > Quick question because I'm lazy: what does IMAP do when you ask
> > > for the "received" fields?
> >
> > It returns the "entire" received fields, in one block.
>
> Sensible and useful.
8-)
Unfortunately, because of the way the header_t is done, maiutils/imap4d
has a different behaviour, where UW-imap returns:
Received: from spock2.ECE.McGill.CA (address@hidden [132.206.1.2])
by qnx.com (8.8.8/8.8.8) with ESMTP id JAA21691
for <address@hidden>; Tue, 16 May 2000 09:15:27 -0400
Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
by spock2.ECE.McGill.CA (8.8.8/8.8.8) with ESMTP id JAA24089
Received: from spock2.ECE.McGill.CA (address@hidden [132.206.1.2])
by qnx.com (8.8.8/8.8.8) with ESMTP id JAA21691
for <address@hidden>; Tue, 16 May 2000 09:15:27 -0400
from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
by spock2.ECE.McGill.CA (8.8.8/8.8.8) with ESMTP id JAA24089
sigh .. I think this is a bug, although it is conforming both
to RFC8222 and to RFC2060(IMAP) But somehow I don't thing
this is good .. The approach was to let header_get_value()
coalesce the fields, so :
To: address@hidden
To: address@hidden
Will be return like "address@hidden address@hidden".
> Btw. The envelope_t doesn't seem to give the smtp envelope information
> as I thought it would, just From and date (what shows up in mbox, I
> think).
No not really, for the on-disk mailbox the from/date envelope
maps to the "From " separator of the message in mbox format.
For IMAP it maps to the "Sender" and imap INTERNALDATE command.
> There's an optional "envelope" feature that sieve can provide
> that alows filtering on the smtp "rcpt from" and "mail to" dialogs.
8-)
I think you mean "Mail From" and "Rcpt To:".
Sendmail usually passes the "Rcpt To" to the delivery program(MDA)(sendmail.cf)
usually to /bin/mail or similar. The MDA will use the envelope
from for the message separator on Unix/Mbox "From ".
> That info isn't available, at least portably, is it?
No not really, for example maildir(qmail), mh, etc ... does not use it.
> Don't some smtp receivers put it in the mail before storing it to disk?
Not portably, it may be pass by the MTA(sendmail) to the MDA(/bin/mail) but
the MDA can do whatever with it. And not all MTA's will pass it, for
exemple I'm not sure what qmail is doing with it.
> p.s. And the "path" scheme only works with full paths, which is kind
> of cheesy, I'd like to make it work for relative paths as well, I
> guess I can look at the _is_scheme memthod? I have to look into this,
> I'll be pretty unhappy if I can't sieve "~/mbox"...
8-), "~" is a shell expansion mechanism. If you do
# cd mailutils/frm
# MAIL=~/mbox ./frm
...
It will work, because the shell will do the expansion for you.
But Jakob and Jeff wanted someway to let a sys admin set the default
mail spooldir base on a user/system basis. So they came up with
mailbox_create_default (mailbox_t *, const char *);
Where all sort of system dependent things are done, like :
mailbox_create_default (&mbox, "sam");
could open /etc/mailutils.conf and search for "sam" and the path of
your mailbox
--- /etc/mailbox.conf
sam = imap://host.name.net/INBOX # redirect user sam elsewere.
----
So yes, "~" or "~sam" can be implemented quite easily 8-).
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- sieve, and header_t's api, Sam Roberts, 2001/04/22
- Re: sieve, and header_t's api, Alain Magloire, 2001/04/22
- Message not available
- Re: sieve, and header_t's api, Sam Roberts, 2001/04/23
- Re: sieve, and header_t's api,
Alain Magloire <=
- Bug in mapfile_stream.c, Sergey Poznyakoff, 2001/04/23
- Sergey(patch mbx_mbox.c), Alain Magloire, 2001/04/23
- POP3d locking, Alain Magloire, 2001/04/23
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24
- Re: POP3d locking, Alain Magloire, 2001/04/24
- Re: POP3d locking, Sergey Poznyakoff, 2001/04/24