Re: [Dbmail] #noattach mode

2009-05-13 Thread Marc Dirix
http://lmgtfy.com/?q=douglas+adams Marc ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: [Dbmail] #noattach mode

2009-05-12 Thread Michael Monnerie
On Dienstag 12 Mai 2009 Jorge Bastos wrote: > Good to know that I'm forgiven :P > Who was he? Oh Lord ;-) Wikipedia rules: http://en.wikipedia.org/wiki/Douglas_Adams mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .netwo

Re: [Dbmail] #noattach mode

2009-05-12 Thread Jorge Bastos
> PS: Those not knowing Douglas Adams are forgiven. Good to know that I'm forgiven :P Who was he? ___ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Re: [Dbmail] #noattach mode

2009-05-12 Thread Michael Monnerie
On Dienstag 12 Mai 2009 Daniel Urstöger wrote: > > Usermapped ip/port or via a special 'virtual' username extension > > '#mobile' or '#noattach' or whatever is decided on. > > Those are the kinds of changes I am quite sure you are the only one   > capable of doing that, right? ;) Well, with a good

Re: [Dbmail] #noattach mode

2009-05-12 Thread Daniel Urstöger
> Daniel Urstöger wrote: >> Talking about breaking the RFC, I wonder if I got this wrong or >> right: >> the plan is to put another interface to the database via the dbmail >> daemon, >> that would offer that as additional functionality, right? > > Well, 'plan' is somewhat optimistic. 'Design id

Re: [Dbmail] #noattach mode

2009-05-12 Thread Paul J Stevens
Daniel Urstöger wrote: > Talking about breaking the RFC, I wonder if I got this wrong or right: > the plan is to put another interface to the database via the dbmail > daemon, > that would offer that as additional functionality, right? Well, 'plan' is somewhat optimistic. 'Design idea' would des

Re: [Dbmail] #noattach mode

2009-05-12 Thread Daniel Urstöger
Talking about breaking the RFC, I wonder if I got this wrong or right: the plan is to put another interface to the database via the dbmail daemon, that would offer that as additional functionality, right? So actually inside the database the message will not get altered in any way, so I can see

Re: [Dbmail] #noattach mode

2009-05-11 Thread Michael Monnerie
On Dienstag 12 Mai 2009 Jonathan Feally wrote: > This could > pose a big problem with the fact that all messages in a mailbox would > have to be rewritten before a simple list command could be fulfilled > as the size of the messages would be different than what is stored > already in a column. We

Re: [Dbmail] #noattach mode

2009-05-11 Thread Michael Monnerie
On Montag 11 Mai 2009 Paul J Stevens wrote: > > Not to be nasty with the name, but I think #mobile is not as good a > > name as #noattach, as I might want #mobile mode also when I'm at an > > internet cafe, or other environment. > > ?? Most people are mobile when in a cafe. Also #mobile sounds bett

Re: [Dbmail] #noattach mode

2009-05-11 Thread Jonathan Feally
Not to burst anyone's bubble, but we are talking about having dbmail intelligently rewrite messages for clients on demand. This could pose a big problem with the fact that all messages in a mailbox would have to be rewritten before a simple list command could be fulfilled as the size of the me

Re: [Dbmail] #noattach mode

2009-05-11 Thread Paul J Stevens
Michael Monnerie wrote: > On Montag 11 Mai 2009 Paul J Stevens wrote: >> Of course, you could have some mailclient use the virtual userid >> directly without using usermap, but with usermap all you'd have to >> explain to your mobile device users would be to use an other >> servername. > > But tha

Re: [Dbmail] #noattach mode

2009-05-11 Thread Michael Monnerie
On Montag 11 Mai 2009 Paul J Stevens wrote: > Of course, you could have some mailclient use the virtual userid > directly without using usermap, but with usermap all you'd have to > explain to your mobile device users would be to use an other > servername. But that servername needs another IP, rig

Re: [Dbmail] #noattach mode

2009-05-11 Thread Paul J Stevens
Michael Monnerie wrote: > On Montag 11 Mai 2009 Josh Marshall wrote: >> Not sure on your setup, but if you have access to multiple IP >> addresses, you can put a rule on the firewall to forward port 110 to >> e.g. 111 on the internal server. Otherwise default to internal >> clients connect to port

Re: [Dbmail] #noattach mode

2009-05-10 Thread Michael Monnerie
On Montag 11 Mai 2009 Josh Marshall wrote: > Not sure on your setup, but if you have access to multiple IP > addresses, you can put a rule on the firewall to forward port 110 to > e.g. 111 on the internal server. Otherwise default to internal > clients connect to port 110 and external clients conne

Re: [Dbmail] #noattach mode

2009-05-10 Thread Josh Marshall
> Yes, that's better. But aren't there phones/clients where you cannot > even configure a port? Not sure on your setup, but if you have access to multiple IP addresses, you can put a rule on the firewall to forward port 110 to e.g. 111 on the internal server. Otherwise default to internal client

Re: [Dbmail] #noattach mode

2009-05-08 Thread Michael Monnerie
On Freitag 08 Mai 2009 Paul J Stevens wrote: > We'd have to make sure this doesn't break any rfcs. Do you mean the POP non-delete part? I'd say either you refuse deletion when in #noattach mode, or only allow IMAP then. I guess it's better to allow POP but refuse delete, in order to support as

Re: [Dbmail] #noattach mode

2009-05-08 Thread Paul J Stevens
Michael Monnerie wrote: > On Donnerstag 07 Mai 2009 Paul J Stevens wrote: >> The dbmail-httpd would then, after authentication/authorization >> return the attachment involved with the correct mime headers for the >> relevant content, i.e. the message, so the client knows how to save >> the file. >

Re: [Dbmail] #noattach mode (was: Dbmail Hybrid)

2009-05-07 Thread Michael Monnerie
On Donnerstag 07 Mai 2009 Paul J Stevens wrote: > The dbmail-httpd would then, after authentication/authorization > return the attachment involved with the correct mime headers for the > relevant content, i.e. the message, so the client knows how to save > the file. Could that be done in a virtual