[xmail] Re: Abemus Papam ...
Has someone created an ebuild for 1.21 yet? If not, I will create it
and submit it to gentoo's bugzilla. Kevin, is it alright if I update
the ebuild you sent me? I prefer it to the chrooted version.
Dustin C. Hatch
http://www.dchweb.com/
Davide Libenzi wrote:
>1.21 it is, at the end:
>
>http://www.xmailserver.org
>
>* Sun Jan 9 2005 Davide Libenzi
>Added a fix for 64 bits porting compatibility.
>Added the ability to exclude filters from execution in case of
> authenticated user.
>By pre-pending the filter command token with a token containing "!aex",
> the filters
>won't be run if the user authenticated himself.
>Added @@USERAUTH macro even to standard in/out filters (before it was only
> defined
>for SMTP ones).
>Added a new "NoSenderBounce" variable inside the SERVER.TAB file, to enable
>XMail generated bounce messages to have the empty SMTP sender ('MAIL
> FROM:<>').
>Added a new "SMTP-MaxErrors" variable inside the SERVER.TAB file to set
> the maximum
>errors allowed in a single SMTP session (default zero, unlimited).
>Added a "LastLoginTimeDate" variable to the "userstat" CTRL command.
>Added external aliases support in the CTRL protocol.
>The MESSAGE.ID file is now automatically created, if missing.
>Changed the logic used to treat domain and user MAILPROC.TAB files.
> Before, a user's
>MAILPROC.TAB was overriding the domain one, while now the rules are merged
> together,
>with domain's ones first, followed by user's ones.
>The maximum mailbox size of zero is now interpreted as unlimited.
>Fixed XMail's sendmail to detect non-RFC822 data and handle it correctly.
>The IP:PORT addresses emission in spool files (and Received: lines) has
> been changed
>to the form [IP]:PORT.
>Added filter logging, that is enabled with the new -Qg command line option.
>Fixed an error message in the SMTP server, that was triggered by the
> remote client
>not using the proper syntax for the "MAIL FROM:" and "RCPT TO:" commands.
>Fixed explicit routing through SMTPGW.TAB file.
>Fixed a possible problem with file locking that might be triggered from
> CTRL commands
>cfgfileget/cfgfileset.
>Added a check to avoid the CTRL server to give an error when a domain
> created with
>older versions of XMail does not have the domain directory inside
> cmdaliases.
>The SMTP server FQDN variable should be set to the value of
> "SmtpServerDomain", when
>this is used inside the SERVER.TAB file.
>
>
>
>- Davide
>
>-
>To unsubscribe from this list: send the line "unsubscribe xmail" in
>the body of a message to [EMAIL PROTECTED]
>For general help: send the line "help" in the body of a message to
>[EMAIL PROTECTED]
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
[xmail] R: Re: New Admin Protocol Commands
I guess you are working on "Certified E-mail (PEC)" as proposed by italian goverment... Are you? Dario -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Luca Giuranna Inviato: lunedì 10 gennaio 2005 21.02 A: xmail@xmailserver.org Oggetto: [xmail] Re: New Admin Protocol Commands >>it would be useful to have some admin commands to deal with messages >>scheduled for resend (those in the rsnd folders in the spool tree), the >>same way xmail has commands to deal with frozen messages. >>They could be "rsndlist", "rsndgetlog" and "rsndgetmsg", like the >>"froz..." equivalents. > Why would we need them? I mean, message are already rescheduled for > delivery. In my personal case the mail server i'm working on is part of a complex system where mail delivery is of primary importance and the system must know if a message is deferred and the reason why. By analizing xmail log files is possible to discovery if a message has not been sent, then, by looking for the frozen message, one can know that the message has bounced and why. If it is just deferred, there is no frozen message and the only way to know why is to look for the rsnd/slog pair in the spool tree. Not that this is a big problem, in fact I was able to write a small software to accomplish this, but I think that, conceptually, frozen and deferred message are both problems that a system may want to be informed about and new admin commands would make xmail more internally coherent. Of course this is just my opinion, maybe I'm the only one in the world with such needs :-) -- Luca Giuranna - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: New Admin Protocol Commands
>>it would be useful to have some admin commands to deal with messages >>scheduled for resend (those in the rsnd folders in the spool tree), the >>same way xmail has commands to deal with frozen messages. >>They could be "rsndlist", "rsndgetlog" and "rsndgetmsg", like the >>"froz..." equivalents. > Why would we need them? I mean, message are already rescheduled for > delivery. In my personal case the mail server i'm working on is part of a complex system where mail delivery is of primary importance and the system must know if a message is deferred and the reason why. By analizing xmail log files is possible to discovery if a message has not been sent, then, by looking for the frozen message, one can know that the message has bounced and why. If it is just deferred, there is no frozen message and the only way to know why is to look for the rsnd/slog pair in the spool tree. Not that this is a big problem, in fact I was able to write a small software to accomplish this, but I think that, conceptually, frozen and deferred message are both problems that a system may want to be informed about and new admin commands would make xmail more internally coherent. Of course this is just my opinion, maybe I'm the only one in the world with such needs :-) -- Luca Giuranna - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: New Admin Protocol Commands
On Mon, 10 Jan 2005, Charles Frolick wrote: > Hello Davide, > > Monday, January 10, 2005, 12:37:27 PM, you wrote: > > DL> Why would we need them? I mean, message are already rescheduled for > DL> delivery. > > I know on some other servers they allow you to browse and force resend > messages, this is good when you have a long delay between reties and > maybe you lost your network connection, of course, the way you handle > resend scheduling, it makes less sense. The other MTA's I've used > with this send all queued mail at once on a schedule. We do have ETRN for that. Just do an "ETRN [EMAIL PROTECTED]" and this reschedules all queued message for immediate delivery. - Davide - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: New Admin Protocol Commands
Hello Davide, Monday, January 10, 2005, 12:37:27 PM, you wrote: DL> Why would we need them? I mean, message are already rescheduled for DL> delivery. I know on some other servers they allow you to browse and force resend messages, this is good when you have a long delay between reties and maybe you lost your network connection, of course, the way you handle resend scheduling, it makes less sense. The other MTA's I've used with this send all queued mail at once on a schedule. -- Best regards, Charlesmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: New Admin Protocol Commands
On Sun, 9 Jan 2005, Luca Giuranna wrote: > Hi, > > I'm working heavily on XMail logging features for a demanding customer > and I have some ideas on possible improvements. > I've not yet thinked enough about these improvements, so, for now, I > save you from reading about them. > > One thing, howewer, seems ok to me for a request to Davide. > > it would be useful to have some admin commands to deal with messages > scheduled for resend (those in the rsnd folders in the spool tree), the > same way xmail has commands to deal with frozen messages. > They could be "rsndlist", "rsndgetlog" and "rsndgetmsg", like the > "froz..." equivalents. Why would we need them? I mean, message are already rescheduled for delivery. - Davide - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: Abemus Papam ...
On Mon, 10 Jan 2005, Francesco Vertova wrote: > It isn't Italian, but Latin, and (with a leading "h") means "We have the > Pope" (the Vatican's ritual formula to announce that the new Pope has been > elected) ... Ouch, true! I wish I wouldn't have skipped that Latin lesson to go at the beach ... :-) - Davide - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: HeloDomain question
At 09:01 1/10/2005, S=F6nke Ruempler wrote: > > What do you think? What could be the implications of the > > current status, > > and of changing it? Does it even matter (SPAM scores maybe? I don't > > know..)?=3D20 > >Yes, the HELO and the RDNS of your outgoing IP should be the same to =3D >avoid >other software complaining. Other software would complain only at peril of violation of RFC-2821,=20 section 4.1.4: An SMTP server MAY verify that the domain name parameter in the EHLO=20 command actually corresponds to the IP address of the client. However, the= =20 server MUST NOT refuse to accept a message for this reason if the=20 verification fails: the information about verification failure is for=20 logging and tracing only. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: HeloDomain question
[EMAIL PROTECTED] wrote on Monday, January 10, 2005 2:35 PM: > What do you think? What could be the implications of the > current status, > and of changing it? Does it even matter (SPAM scores maybe? I don't > know..)?=20 Yes, the HELO and the RDNS of your outgoing IP should be the same to = avoid other software complaining. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] HeloDomain question
Hello everyone, My current HeloDomain is set to one of my domains (The first one I had, actually). However, a reverse resolve on my IP gives something else, not that domain or a name under it. I was wondering if maybe it would be better to set my HeloDomain to what my IP resolves to, or maybe even RootDomain? (I wouldn't chnge POP3Domain because that would require people to change their settings, and it has nothing to do with it anyway) What do you think? What could be the implications of the current status, and of changing it? Does it even matter (SPAM scores maybe? I don't know..)? Thanks! Liron. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: Abemus Papam ...
At 22.59 10/01/05 +1100, you wrote: >Thanks Davide, Would you believe Google can't translate "Abemus Papam" >There are numerous google hits, but I have been unable to workout what you >said - only I think it is related to "Finally" > >Could you enlighten the non Italian speaking world? It isn't Italian, but Latin, and (with a leading "h") means "We have the Pope" (the Vatican's ritual formula to announce that the new Pope has been elected) ... Ciao, Francesco - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
[xmail] Re: Abemus Papam ...
http://www.google.com/search?q=Habemus+Papam
We have a pope. Or in XMail's case, POP. And SMTP. And sometime
(hopefully) soon, IMAP too. :)
Rob Arends wrote:
>Thanks Davide, Would you believe Google can't translate "Abemus Papam"
>There are numerous google hits, but I have been unable to workout what you
>said - only I think it is related to "Finally"
>
>Could you enlighten the non Italian speaking world?
>
>Ta, Rob :-)
>
>_
>Note To Self: Remember to put something witty here later...
>
>
>
>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Davide Libenzi
>>Sent: Monday, 10 January 2005 10:21 AM
>>To: XMail Announce; XMail mailing list
>>Subject: [xmail] Abemus Papam ...
>>
>>
>>1.21 it is, at the end:
>>
>>http://www.xmailserver.org
>>
>>* Sun Jan 9 2005 Davide Libenzi
>>Added a fix for 64 bits porting compatibility.
>>Added the ability to exclude filters from execution in
>>case of authenticated user.
>>By pre-pending the filter command token with a token
>>containing "!aex", the filters
>>won't be run if the user authenticated himself.
>>Added @@USERAUTH macro even to standard in/out filters
>>(before it was only defined
>>for SMTP ones).
>>Added a new "NoSenderBounce" variable inside the
>>SERVER.TAB file, to enable
>>XMail generated bounce messages to have the empty SMTP
>>sender ('MAIL FROM:<>').
>>Added a new "SMTP-MaxErrors" variable inside the
>>SERVER.TAB file to set the maximum
>>errors allowed in a single SMTP session (default zero, unlimited).
>>Added a "LastLoginTimeDate" variable to the "userstat"
>>CTRL command.
>>Added external aliases support in the CTRL protocol.
>>The MESSAGE.ID file is now automatically created, if missing.
>>Changed the logic used to treat domain and user
>>MAILPROC.TAB files. Before, a user's
>>MAILPROC.TAB was overriding the domain one, while now the
>>rules are merged together,
>>with domain's ones first, followed by user's ones.
>>The maximum mailbox size of zero is now interpreted as unlimited.
>>Fixed XMail's sendmail to detect non-RFC822 data and
>>handle it correctly.
>>The IP:PORT addresses emission in spool files (and
>>Received: lines) has been changed
>>to the form [IP]:PORT.
>>Added filter logging, that is enabled with the new -Qg
>>command line option.
>>Fixed an error message in the SMTP server, that was
>>triggered by the remote client
>>not using the proper syntax for the "MAIL FROM:" and
>>"RCPT TO:" commands.
>>Fixed explicit routing through SMTPGW.TAB file.
>>Fixed a possible problem with file locking that might be
>>triggered from CTRL commands
>>cfgfileget/cfgfileset.
>>Added a check to avoid the CTRL server to give an error
>>when a domain created with
>>older versions of XMail does not have the domain
>>directory inside cmdaliases.
>>The SMTP server FQDN variable should be set to the value
>>of "SmtpServerDomain", when
>>this is used inside the SERVER.TAB file.
>>
>>
>>
>>- Davide
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe
>>xmail" in the body of a message to [EMAIL PROTECTED]
>>For general help: send the line "help" in the body of a
>>message to [EMAIL PROTECTED]
>>
>>
>>
>>
>
>-
>To unsubscribe from this list: send the line "unsubscribe xmail" in
>the body of a message to [EMAIL PROTECTED]
>For general help: send the line "help" in the body of a message to
>[EMAIL PROTECTED]
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
[xmail] Re: Abemus Papam ...
Thanks Davide, Would you believe Google can't translate "Abemus Papam"
There are numerous google hits, but I have been unable to workout what you
said - only I think it is related to "Finally"
Could you enlighten the non Italian speaking world?
Ta, Rob :-)
_
Note To Self: Remember to put something witty here later...
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Davide Libenzi
> Sent: Monday, 10 January 2005 10:21 AM
> To: XMail Announce; XMail mailing list
> Subject: [xmail] Abemus Papam ...
>
>
> 1.21 it is, at the end:
>
> http://www.xmailserver.org
>
> * Sun Jan 9 2005 Davide Libenzi
> Added a fix for 64 bits porting compatibility.
> Added the ability to exclude filters from execution in
> case of authenticated user.
> By pre-pending the filter command token with a token
> containing "!aex", the filters
> won't be run if the user authenticated himself.
> Added @@USERAUTH macro even to standard in/out filters
> (before it was only defined
> for SMTP ones).
> Added a new "NoSenderBounce" variable inside the
> SERVER.TAB file, to enable
> XMail generated bounce messages to have the empty SMTP
> sender ('MAIL FROM:<>').
> Added a new "SMTP-MaxErrors" variable inside the
> SERVER.TAB file to set the maximum
> errors allowed in a single SMTP session (default zero, unlimited).
> Added a "LastLoginTimeDate" variable to the "userstat"
> CTRL command.
> Added external aliases support in the CTRL protocol.
> The MESSAGE.ID file is now automatically created, if missing.
> Changed the logic used to treat domain and user
> MAILPROC.TAB files. Before, a user's
> MAILPROC.TAB was overriding the domain one, while now the
> rules are merged together,
> with domain's ones first, followed by user's ones.
> The maximum mailbox size of zero is now interpreted as unlimited.
> Fixed XMail's sendmail to detect non-RFC822 data and
> handle it correctly.
> The IP:PORT addresses emission in spool files (and
> Received: lines) has been changed
> to the form [IP]:PORT.
> Added filter logging, that is enabled with the new -Qg
> command line option.
> Fixed an error message in the SMTP server, that was
> triggered by the remote client
> not using the proper syntax for the "MAIL FROM:" and
> "RCPT TO:" commands.
> Fixed explicit routing through SMTPGW.TAB file.
> Fixed a possible problem with file locking that might be
> triggered from CTRL commands
> cfgfileget/cfgfileset.
> Added a check to avoid the CTRL server to give an error
> when a domain created with
> older versions of XMail does not have the domain
> directory inside cmdaliases.
> The SMTP server FQDN variable should be set to the value
> of "SmtpServerDomain", when
> this is used inside the SERVER.TAB file.
>
>
>
> - Davide
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> xmail" in the body of a message to [EMAIL PROTECTED]
> For general help: send the line "help" in the body of a
> message to [EMAIL PROTECTED]
>
>
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
