Long queue_id collision probability with multiple servers?
Can long queue_ids be used as a globally unique identifier within a multi server setup? I guess the chances decrease as the disk space and inode numbers increase and increase as the number of servers and number of mails processed increase. I was not able to do the math but trying to come up with a mathematically sound reason to use them for this purpose or not. Any ideas? Thanks -- Mehmet
Re: Long queue_id collision probability with multiple servers?
Mehmet Tolga Avcioglu: > Can long queue_ids be used as a globally unique identifier within a multi > server setup? As documented, the queue ID is made up from inode number and time. The inode number is unique only within a single file system. Wietse
Re: Long queue_id collision probability with multiple servers?
On Sat, Dec 13, 2014 at 2:52 PM, Wietse Venema wrote: > > Mehmet Tolga Avcioglu: > > Can long queue_ids be used as a globally unique identifier within a multi > > server setup? > > As documented, the queue ID is made up from inode number and time. > The inode number is unique only within a single file system. > Thank you for the reply. Yes, micro seconds and inode number. Wondering the probability of hitting the same queue id on one server after a time correction, or probability of hitting the same queue id on multiple servers. Thinking about it, it should be quite low and on par with basic hashing functions, but I was not able to do the math. From your answer I guess I shouldn't look any further and just add the hostname behind the queue id. But, on that note, adding a single random character would have probably made it as good as many hashing functions. Thanks again -- Mehmet
Re: Long queue_id collision probability with multiple servers?
Mehmet Tolga Avcioglu: > On Sat, Dec 13, 2014 at 2:52 PM, Wietse Venema wrote: > > > > Mehmet Tolga Avcioglu: > > > Can long queue_ids be used as a globally unique identifier within a multi > > > server setup? > > > > As documented, the queue ID is made up from inode number and time. > > The inode number is unique only within a single file system. > > > > Thank you for the reply. > > Yes, micro seconds and inode number. As documented, long queue IDs also include the epoch time in seconds. > Wondering the probability of hitting the same queue id on one > server after a time correction, Don't do that. Run proper time synchronization software instead of resetting clocks. Wietse
Re: Long queue_id collision probability with multiple servers?
On Sat, Dec 13, 2014 at 4:24 PM, Wietse Venema wrote: > > Yes, micro seconds and inode number. > > As documented, long queue IDs also include the epoch time in seconds. > Yes, I meant time in microsecond resolution. That is mainly the reason why I thought about using it globally, but I'll use queue_id@hostname instead. Thanks -- Mehmet
Re: A highly goofed installation Postfix/Dovecot/Squirrelmail
Thanks for the feedback on the Dovecot issue. It is great knowing that I'll be approaching the Dovecot volunteers prepared in the sense of Postfix being in fairly good shape. I slept with one nagging question about my hostname... > >/etc/hostname ># begin /etc/hostname > example.com ># eof > >/etc/mailname ># begin /etc/mailname > example.com ># eof > and that it is only 'example.com' instead of something like 'mail.example.com' or 'foo.example.com' I omitted such a longer name because this machine does so much more than mail or foo. But did I abuse the intent of the file? I noticed that the package installed did some wacky stuff when it generated mydestination, like with the localhost.com being generated. It's somewhat irrelevant because it ended up being commented out of my main.cf anyway, but was my choice for a simplified hostname a hazardous move or a bad practice? > ># Verified that myhostname is set to the FQDN, and it is >myhostname = example.com ># End of verified myhostname section > > ># There is a table in MySQL that stores the aliases so are ># these next two lines even relevant??? >alias_maps = hash:/etc/aliases >alias_database = hash:/etc/aliases >myorigin = /etc/mailname > ># I was asked to modify this parameter >#mydestination = example.com, localhost.com, , localhost >mydestination = localhost ># end of this modified section >
Re: Exempt domain before postscreen tests?
Am 12.12.2014 um 15:48 schrieb Noel Jones: On 12/12/2014 8:24 AM, Isaac Grover wrote: Good morning, We have users on a domain who are convinced they are losing emails due to our spam filtering (postscreen, amavis, spamassassin). We have shown them logs of legitimate spam being filtered with no false positives, but they want to be exempt from all spam filtering. Is it possible to exempt their domain from postscreen filtering, so they receive every single email addressed to anyone in their organization, spam or not? Postscreen filtering happens when the client initially connects, even before the hostname lookup. The only postscreen whitelisting possible is by client IP. This is by design true it is by deisgn but not because postscreen don't know the RCPT/Sender in enforcing mode it logs the complete envelope including HELO which is mandatory if you are responsible for others mailboxes because you need to be able answer question if a specific mail was blocked and why
Re: A highly goofed installation Postfix/Dovecot/Squirrelmail
On 12 Dec 2014, at 22:47, ghalvor...@hushmail.com wrote: Hello friends, I followed a HOWTO document and it wasn't an entire success. I do want to be more proficient with Postfix and have bought The Book of Postfix from No Starch and Postfix: The Definitive Guide from O'Reilly. I've spent about 15 hours in each book, so hopefully I have a vague idea of how it works. Note that those are both quite old. They are solid references for their times and because Dr. Venema is very careful about backward compatibility they are mostly not wrong, but they cannot help you with the setup of the many features added to Postfix in the past 8-10 years. The HOWTO is: https://www.digitalocean.com/community/tutorials/how-to-configure-a-mail-server-using-postfix-dovecot-mysql-and-spamassasin That seems a bit more modern, but it is mostly instructions for operating Things That Are Not Postfix. [...] So when I send a test email from my MacBook using mail in the command line, I get these in mail.log. I get many, many of these. For now, I'm mainly concerned with the postfix error. The Dovecot stuff, I can refer to their list once the Postfix is in good shape. The /var/spool/ and /var/mail/ directories seem to be unchanged, which is a bit disturbing (maybe a permissions problem?) Dec 12 21:52:06 example postfix/qmgr[29911]: 21EDCC08A3: from=, size=578, nrcpt=1 (queue active) Dec 12 21:52:06 example dovecot: lmtp(30139): Connect from local Dec 12 21:52:06 example dovecot: lmtp(30139, b...@example.com): Error: user b...@example.com: Initialization failed: namespace configuration error: inbox=yes namespace missing Dec 12 21:52:06 example dovecot: lmtp(30139): Disconnect from local: Successful quit Dec 12 21:52:06 example postfix/lmtp[30138]: 21EDCC08A3: to=, relay=example.com[private/dovecot-lmtp], delay=1021, delays=1021/0.02/0.02/0.04, dsn=4.3.0, status=deferred (host example.com[private/dovecot-lmtp] said: 451 4.3.0 Temporary internal error (in reply to end of DATA command)) That is entirely a Dovecot problem. The first line is purely informational and the final line is just a record of the Dovecot LMTP response.
Re: Exempt domain before postscreen tests?
On 12/13/2014 1:51 PM, li...@rhsoft.net wrote: > > Am 12.12.2014 um 15:48 schrieb Noel Jones: >> On 12/12/2014 8:24 AM, Isaac Grover wrote: >>> Good morning, >>> >>> We have users on a domain who are convinced they are losing emails >>> due to our spam filtering (postscreen, amavis, spamassassin). We >>> have shown them logs of legitimate spam being filtered with no false >>> positives, but they want to be exempt from all spam filtering. >>> >>> Is it possible to exempt their domain from postscreen filtering, so >>> they receive every single email addressed to anyone in their >>> organization, spam or not? >> >> Postscreen filtering happens when the client initially connects, >> even before the hostname lookup. The only postscreen whitelisting >> possible is by client IP. This is by design > > true it is by deisgn > > but not because postscreen don't know the RCPT/Sender > > in enforcing mode it logs the complete envelope including HELO which > is mandatory if you are responsible for others mailboxes because you > need to be able answer question if a specific mail was blocked and why Postscreen is not a proxy. When postscreen logs the helo/sender/recipient, it is because the decision to reject has already been made, and a "stub" smtp server gathers that information specifically for logging. At the point in time when postscreen must decide to pass a client, only the client IP is known. Therefore, whitelisting can only be done by client IP. I suppose postscreen could be re-engineered to gather more information before making a pass/fail decision, but then we would need to call it postproxy, which seems like an awkward name. More importantly, that would violate the "lightweight, high volume, low latency" design goals. -- Noel Jones
Re: Long queue_id collision probability with multiple servers?
On 12/14/2014 04:28 AM, Mehmet Tolga Avcioglu wrote: > Yes, I meant time in microsecond resolution. That is mainly the reason > why I thought about using it globally, but I'll use queue_id@hostname > instead. Or you could just use the message ID which is exactly this anyways. Peter
Re: Long queue_id collision probability with multiple servers?
On Sun, Dec 14, 2014 at 11:46:28AM +1300, Peter wrote: > On 12/14/2014 04:28 AM, Mehmet Tolga Avcioglu wrote: > > Yes, I meant time in microsecond resolution. That is mainly the reason > > why I thought about using it globally, but I'll use queue_id@hostname > > instead. > > Or you could just use the message ID which is exactly this anyways. Not quite. The same message-id can as a result of envelope splitting arrive as separate messages. -- Viktor.
Re: A highly goofed installation Postfix/Dovecot/Squirrelmail
OK. So these are a little dated. Any recommendations for HOWTOs that are a more up to date. On 12/13/2014 5:33 PM, Bill Cole wrote: On 12 Dec 2014, at 22:47, ghalvor...@hushmail.com wrote: Hello friends, I followed a HOWTO document and it wasn't an entire success. I do want to be more proficient with Postfix and have bought The Book of Postfix from No Starch and Postfix: The Definitive Guide from O'Reilly. I've spent about 15 hours in each book, so hopefully I have a vague idea of how it works. Note that those are both quite old. They are solid references for their times and because Dr. Venema is very careful about backward compatibility they are mostly not wrong, but they cannot help you with the setup of the many features added to Postfix in the past 8-10 years. The HOWTO is: https://www.digitalocean.com/community/tutorials/how-to-configure-a-mail-server-using-postfix-dovecot-mysql-and-spamassasin That seems a bit more modern, but it is mostly instructions for operating Things That Are Not Postfix. [...] So when I send a test email from my MacBook using mail in the command line, I get these in mail.log. I get many, many of these. For now, I'm mainly concerned with the postfix error. The Dovecot stuff, I can refer to their list once the Postfix is in good shape. The /var/spool/ and /var/mail/ directories seem to be unchanged, which is a bit disturbing (maybe a permissions problem?) Dec 12 21:52:06 example postfix/qmgr[29911]: 21EDCC08A3: from=, size=578, nrcpt=1 (queue active) Dec 12 21:52:06 example dovecot: lmtp(30139): Connect from local Dec 12 21:52:06 example dovecot: lmtp(30139, b...@example.com): Error: user b...@example.com: Initialization failed: namespace configuration error: inbox=yes namespace missing Dec 12 21:52:06 example dovecot: lmtp(30139): Disconnect from local: Successful quit Dec 12 21:52:06 example postfix/lmtp[30138]: 21EDCC08A3: to=, relay=example.com[private/dovecot-lmtp], delay=1021, delays=1021/0.02/0.02/0.04, dsn=4.3.0, status=deferred (host example.com[private/dovecot-lmtp] said: 451 4.3.0 Temporary internal error (in reply to end of DATA command)) That is entirely a Dovecot problem. The first line is purely informational and the final line is just a record of the Dovecot LMTP response.
Re: A highly goofed installation Postfix/Dovecot/Squirrelmail
Believe me, if there was a newer book, I would have gladly bought it. It did worry me that it was as old as it was, but I gather that the email protocol has changed very little over the past 15 years. A HOWTO that has been around for a few months is still nice, especially if the author maintains it so that the flaws and errors are corrected as people point them out. I am really surprised at how no one really adopts the crowd-source wiki approach. It seems that everybody wants their document in a sterile bubble of web space where people can look, but can't touch. On December 13, 2014 at 9:32 PM, "John" wrote: > >OK. So these are a little dated. >Any recommendations for HOWTOs that are a more up to date. > > >On 12/13/2014 5:33 PM, Bill Cole wrote: >> On 12 Dec 2014, at 22:47, ghalvor...@hushmail.com wrote: >> >>> Hello friends, >>> >>> I followed a HOWTO document and it wasn't an entire success. I >do >>> want to be more proficient with Postfix and have bought The >Book of >>> Postfix from No Starch and Postfix: The Definitive Guide from >>> O'Reilly. I've spent about 15 hours in each book, so hopefully >I >>> have a vague idea of how it works. >> >> Note that those are both quite old. They are solid references >for >> their times and because Dr. Venema is very careful about >backward >> compatibility they are mostly not wrong, but they cannot help >you with >> the setup of the many features added to Postfix in the past 8-10 >years. >> >>> The HOWTO is: >>> >>> https://www.digitalocean.com/community/tutorials/how-to- >configure-a-mail-server-using-postfix-dovecot-mysql-and- >spamassasin >>> >> >> That seems a bit more modern, but it is mostly instructions for >> operating Things That Are Not Postfix. >> >> [...] >>> So when I send a test email from my MacBook using mail in the >command >>> line, I get these in mail.log. I get many, many of these. For >now, >>> I'm mainly concerned with the postfix error. The Dovecot >stuff, I >>> can refer to their list once the Postfix is in good shape. The >>> /var/spool/ and /var/mail/ directories seem to be unchanged, >which is >>> a bit disturbing (maybe a permissions problem?) >>> >>> Dec 12 21:52:06 example postfix/qmgr[29911]: 21EDCC08A3: >>> from=, size=578, nrcpt=1 (queue >active) >>> Dec 12 21:52:06 example dovecot: lmtp(30139): Connect from local >>> Dec 12 21:52:06 example dovecot: lmtp(30139, b...@example.com): >Error: >>> user b...@example.com: Initialization failed: namespace >configuration >>> error: inbox=yes namespace missing >>> Dec 12 21:52:06 example dovecot: lmtp(30139): Disconnect from >local: >>> Successful quit >>> Dec 12 21:52:06 example postfix/lmtp[30138]: 21EDCC08A3: >>> to=, relay=example.com[private/dovecot-lmtp], >>> delay=1021, delays=1021/0.02/0.02/0.04, dsn=4.3.0, >status=deferred >>> (host example.com[private/dovecot-lmtp] said: 451 4.3.0 >>> Temporary internal error (in reply to end of >DATA >>> command)) >> >> That is entirely a Dovecot problem. The first line is purely >> informational and the final line is just a record of the Dovecot >LMTP >> response.
Re: A highly goofed installation Postfix/Dovecot/Squirrelmail
On 13 Dec 2014, at 17:31, John wrote: OK. So these are a little dated. Which does not mean bad or wrong. I can't even judge how dated that Ubuntu HOW-TO is or where it might be wrong: I don't use Ubuntu as a mail platform, it has no date, and it mostly talks about details that refer to things that are Not Postfix which I don't use with Postfix. It might be a great HOWTO. The Postfix parts aren't wrong, to the extent that they exist. Any recommendations for HOWTOs that are a more up to date. Not from me. I'm not competent to evaluate the accessibility and completeness of simplified documentation for mail systems. I think the Postfix docs provide excellent instruction in the setup and management of Postfix, as the Sendmail and Dovecot docs do for those tools. I'm apparently wrong in my judgment that those documents are adequate, since there is a real demand for something else.
Re: A highly goofed installation Postfix/Dovecot/Squirrelmail
On 13 Dec 2014, at 21:53, ghalvor...@hushmail.com wrote: Believe me, if there was a newer book, I would have gladly bought it. It did worry me that it was as old as it was, but I gather that the email protocol has changed very little over the past 15 years. Protocols are mostly stable. Tools implementing those protocols (and deviances from their 'pure' models) are not. The books are not bad or wrong. They are incomplete. For completeness, read current docs. A HOWTO that has been around for a few months is still nice, especially if the author maintains it so that the flaws and errors are corrected as people point them out. I am really surprised at how no one really adopts the crowd-source wiki approach. It seems that everybody wants their document in a sterile bubble of web space where people can look, but can't touch. I've got no problem with crowdsourced evolved documentation. I'm not aware of any such documentation for Postfix that is worth citing. However, the documentation provided in the Postfix distribution is extensive and seems to me (a flawed judge) to be complete and adequate. When last I looked, the same seemed true for Dovecot. Unified detailed documentation fit for a broad audience is a hard problem, because every site is just a little different from every other site.
