Re: mail-bombing

On Sun, 12 Dec 2004, Marek Podmaka wrote: So is there any solution for this? We can't use safe_mode in php, it's too restrictive for most customers. We use postfix (default version in woody) A couple of thoughts: 1. Transparently proxy SMTP to your an MTA you control, which limits the number o

mail-bombing

Hi! Few days earlier one of our customers sent about 90.000 mails using mail() function in php and that's bad... Fortunately most of them stayed in mail queue, but I have been lucky to notice it early. All those mails were for about 4 different addresses, 2 of them wrote us compl

Re: What stripe size for mail server?

Oh yeah ur right. :) The file system itself is written in the stripes and stripe boundaries don't have to correspond to cluster boundaries although I think this would be advantageous. 1 cluster -> 1 stripe would be the optimum speed configuration I think. -- To UNSUBSCRIBE, email to [EMA

Re: What stripe size for mail server?

On Thursday 11 November 2004 09.12, Chris Wagner wrote: > Since you (happy Adrian??) Much easier to read :-) [...] > If u have 32KB stripes so that > almost every file fits in 1 stripe, the leftover space is wasted. So a > 2.5KB file written in a 32 KB stripe wastes 30.5 KB. Err. This statemen

Re: What stripe size for mail server?

Ah, ok that changes everything. "mailboxes" ;) At 12:30 AM 11/11/04 +0100, Marcin Owsiany wrote: >> If u still need RAID 5 then I would make the stripe size equal to >> average file size / number of data disks up to no more than 32KB stripe. > >Since avg file size would be something around 2500

Re: What stripe size for mail server?

or 16k stripes should be fine; even 4k probably wouldn't > hurt much. We are using the default, 64k on a server with 140 users and about 80 mails/second, with a mail store of 27 Gb, with an AMD K6 1.2 GHz, 1 Gb RAM, and three Maxtor Ultra9 7200 PATA disks. No problems. -- Please do not

Re: What stripe size for mail server?

On Wednesday 10 November 2004 23.29, Chris Wagner wrote: It's 'you' - three letters :-) > If u still need RAID 5 then I would make the > stripe size equal to average file size / number of data disks up to no > more than 32KB stripe. To optimize random small reads, it's best if a read can be sati

Re: What stripe size for mail server?

On Wed, Nov 10, 2004 at 05:29:37PM -0500, Chris Wagner wrote: > I would say that RAID 5 is probably overkill for a mail queue. It's not the mail queue. Its the mail store (maildirs). We have no problems with mail queue performance so far. > Unless ur > mail queue is running hundred

Re: What stripe size for mail server?

I would say that RAID 5 is probably overkill for a mail queue. Unless ur mail queue is running hundreds of gigabytes and overloading a single disk, a normal single hard drive is sufficient. Based on ur graph it looks like ur queue is under half a gig. If you want redundancy for the mail queue

What stripe size for mail server?

Hi! http://mail1.expro.pl/~porridge/dist.png shows the distribution of file sizes on our mail server (actually just the partition holding maildirs). The sample was 80 files. "-512" means zero-byte files. "0" means the files whose sizes are greater than zero, but

This Is a Test Mail

-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: postfix mail routing

## Russell Coker ([EMAIL PROTECTED]): > I want to have Postfix route mail to two relays based on the sender. If the > sender is from domain1 then I want to use the relay that is authorised with > SPF for domain1, if the sender is from domain2 then I want to use the relay >

Re: postfix mail routing

On Mi, Nov 03, 2004 at 03:20:28 +1100, Russell Coker <[EMAIL PROTECTED]> wrote: > I want to have Postfix route mail to two relays based on the sender. If the > sender is from domain1 then I want to use the relay that is authorised with > SPF for domain1, if the sender is from

postfix mail routing

I want to have Postfix route mail to two relays based on the sender. If the sender is from domain1 then I want to use the relay that is authorised with SPF for domain1, if the sender is from domain2 then I want to use the relay that has SPF records for domain2. Any ideas on how to do this

Returned mail

--- The message cannot be delivered to the following address. --- [EMAIL PROTECTED]Mailbox unknown or not accepting mail. 550 5.1.1 No such local user: 20rwk Reporting-MTA: [EMAIL PROTECTED] Final-Recipient: rfc822;[EMAIL PROTECTED] Action: failed Status: 5.1.1 Diagnostic-Code: X-Notes

Re: Mail Delivery (failure jcoo...@planetz.com)

On Mon, 25 Oct 2004 03:55, "John Cooper" <[EMAIL PROTECTED]> wrote: > I understand your guys' point, and I appreciate it.What you describe > here sounds nearly identicaly to my auto-responder. But, that may be my > lack of knowledge of how the mail system work

Re: Mail Delivery (failure jcoo...@planetz.com)

On Mon, 25 Oct 2004 03:11, Fraser Campbell <[EMAIL PROTECTED]> wrote: > Spam does not justify spam. I have come to this realization myself only > recently (I am, unfortunately still, a TMDA user). I can understand that You should cease using TMDA. For reference I never respond to TMDA type mes

Re: Mail Delivery (failure jcoo...@planetz.com)

On Sun, 24 Oct 2004 06:29, "John Cooper" <[EMAIL PROTECTED]> wrote: > > John C has requested that > > the following message be removed from the archives. > > My apologies that my autoresponder spammed the list. I've never posted to > the debian-isp list. Apparently someone's machine is infected w

Re: Mail Delivery (failure jcoo...@planetz.com)

On Mon, 25 Oct 2004 12:58, "John Cooper" <[EMAIL PROTECTED]> wrote: > >...spammers drown you in water? > > http://dictionary.reference.com/search?q=metaphor > > >..you want respect? Earn it. > > If earning respect in this crowd requires being disrespectful, then I'm not > interested. Earning res

Re: Documentation of big "mail systems"?

On Mon, Oct 18, 2004 at 03:24:01PM +0200, Aur?lien Beaujean wrote: > So mails are delivered to your backend mailstores by smtp ou lmtp ? Yep. The front-end relays were delivering mail to the backend via SMTP (using a qmail-smtpc patch that I wrote, to help integrate the new system with our

RE: Mail Delivery (failure jcoo...@planetz.com)

>...spammers drown you in water? http://dictionary.reference.com/search?q=metaphor >..you want respect? Earn it. If earning respect in this crowd requires being disrespectful, then I'm not interested. The list admins will either remove my private address from this thread, or they won't. Eithe

Re: Mail Delivery (failure jcoo...@planetz.com)

On Sun, 24 Oct 2004 10:55:01 -0700, John wrote in message <[EMAIL PROTECTED]>: > He could easily have shared his idea with the list, and mailed me > separately at my new address, without (in his words) publically > archiving my private address for spammers to harvest. Do you not > agree that th

RE: Mail Delivery (failure jcoo...@planetz.com)

(or whatever you'd like the > message to say). > In this way very few innocent third parties should be subjected > to your spam. I understand your guys' point, and I appreciate it.What you describe here sounds nearly identicaly to my auto-responder. But, that may be my la

Re: Mail Delivery (failure jcoo...@planetz.com)

On Saturday 23 October 2004 16:29, John Cooper wrote: > Clearly I've touched a nerve with Mr. Coker!  The virtiolic nature of his > response here, and the public posting of my private email address which I > was trying to protect, is simply inane and immature.    Next time, Mr. You are sending un

RE: Mail Delivery (failure jcoo...@planetz.com)

> John C has requested that > the following message be removed from the archives. > My apologies that my autoresponder spammed the list. I've never posted to the debian-isp list. Apparently someone's machine is infected with an email-worm, which has used my jcooper address (which I stopped using

Re: Mail Delivery (failure jcoo...@planetz.com)

For the benefit of interested people. John C has requested that the following message be removed from the archives. Auto-responders ARE spam. They will hit innocent people. Just because most victims of auto-responders don't complain does not mean that the auto-responder is not causing proble

Re: Mail Delivery (failure jcoo...@planetz.com)

On Sat, Oct 23, 2004 at 02:27:24PM +1000, Russell Coker wrote: > On Thu, 21 Oct 2004 22:30, [EMAIL PROTECTED] wrote: > > Due to the unprecedented amount of spam I've been receiving, I'm forced to > > change my email address yet again. My new address is johnc at planetz.com. This is silly reasonin

Re: Mail Delivery (failure jcoo...@planetz.com)

On Thu, 21 Oct 2004 22:30, [EMAIL PROTECTED] wrote: > Due to the unprecedented amount of spam I've been receiving, I'm forced to > change my email address yet again. My new address is johnc at planetz.com. Please don't be stupid. Such auto-responders will get you added to all the spam lists aga

Re: Mail Delivery (failure jcoo...@planetz.com)

ate your records and ***resend your message to my new address***. I won't receive mail sent to the old address anymore. Sorry for the inconvenience! Thanks, -John Original Message -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Documentation of big "mail systems"?

On Tue, Oct 12, 2004 at 11:18:55PM +0200, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote a message of 19 lines which said: > I'm currently writing a proposal for a webmail service for, say, 50 > 000 to 500 000 users. I'm looking for description of existing "

Re: Documentation of big "mail systems"?

Le mardi 19 octobre 2004 à 17:18, Russell Coker écrivait: > A gmail service is entirely different to an ISP mail server. The > common use of an ISP mail server is to allow download and delete via > pop. This thread is a « proposal for a webmail service » so 1Go should be appropriate a

Re: Documentation of big "mail systems"?

On Mon, Oct 18, 2004 at 05:04:16PM +0200, Wouter Verhelst <[EMAIL PROTECTED]> wrote a message of 28 lines which said: > Debian does not need the storage for developers to store their mail > on the project's servers. Sorry, wrong thread. The thread I launched on "big mail

Re: Documentation of big "mail systems"?

On Tue, 19 Oct 2004 00:17, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote: > On Sat, Oct 16, 2004 at 09:41:43PM +1000, > a message of 39 lines which said: > > Getting servers that each have 200G or 300G of storage is easy. > > For a mail server, it means either 1G per us

Re: Documentation of big "mail systems"?

On Mon, Oct 18, 2004 at 05:44:08PM +0200, Christoph Moench-Tegeder wrote: > ## Wouter Verhelst ([EMAIL PROTECTED]): > > Debian does not need the storage for developers to store their mail on > > the project's servers. > > This thread is not about Debian's mai

Re: Documentation of big "mail systems"?

## Wouter Verhelst ([EMAIL PROTECTED]): > > > Getting servers that each have 200G or 300G of storage is easy. > > For a mail server, it means either 1G per user (like gmail gives you) > > for only 300 users or 10M (much less than hotmail) for 30 000 > > users. It i

Re: Documentation of big "mail systems"?

On Mon, Oct 18, 2004 at 04:17:14PM +0200, Stephane Bortzmeyer wrote: > On Sat, Oct 16, 2004 at 09:41:43PM +1000, > Russell Coker <[EMAIL PROTECTED]> wrote > a message of 39 lines which said: > > > Getting servers that each have 200G or 300G of storage is easy. > &g

Re: Documentation of big "mail systems"?

On Sat, Oct 16, 2004 at 09:41:43PM +1000, Russell Coker <[EMAIL PROTECTED]> wrote a message of 39 lines which said: > Getting servers that each have 200G or 300G of storage is easy. For a mail server, it means either 1G per user (like gmail gives you) for only 300 users or 10M (

Re: Documentation of big "mail systems"?

Le vendredi 15 octobre 2004 à 13:13, Paul Dwerryhouse écrivait: > We don't use NFS. Only the LDAP servers are using 2.6.x - everything > else is still on 2.4. So mails are delivered to your backend mailstores by smtp ou lmtp ? No NFS means also that pop/imap daemons are running on the backend mail

Re: Documentation of big "mail systems"?

Le samedi 16 octobre 2004 à 21:46, Russell Coker écrivait: > Is there any way to optimise PHP for speed? Maybe PHP5 is worth trying? We uses php/zend mmcache. With it, we freed 50% of CPU of the machines which run IMP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscrib

Re: Documentation of big "mail systems"?

ictive failure analysis right. And a big SAN is much easier to manage than hundreds of servers with many disks each, of different types. OTOH, any SAN hardware that does not have at least full double redundancy is NOT a good idea at all. > one back-end server go down and take out 1/7 of the ma

Re: Documentation of big "mail systems"?

On Sat, Oct 16, 2004 at 09:41:43PM +1000, Russell Coker wrote: > There's less cables for idiots to trip over or otherwise break > (don't ask), I dare to ask :-) Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D

Re: Documentation of big "mail systems"?

On Fri, 15 Oct 2004 20:08, Paul Dwerryhouse <[EMAIL PROTECTED]> wrote: > On Fri, Oct 15, 2004 at 06:56:21PM +1000, Russell Coker wrote: > > The machines were all running 2.4.2x last time I was there, but they > > may be moving to 2.6.x now. > > All the stores, relays and proxies are still on 2.4.x,

Re: Documentation of big "mail systems"?

nce to benchmark it though). Having multiple back-end servers with local disks reduces the risks (IMHO). There's less cables for idiots to trip over or otherwise break (don't ask), and no single point of failure for the entire network. Having one back-end server go down and take out 1/7

Re: Documentation of big "mail systems"?

## Henrique de Moraes Holschuh ([EMAIL PROTECTED]): > > So, now we would like Russel to explain why he does not like SAN. > He probably doesn't advocate using SAN instead of local disks if you do not > have a good reason to use SAN. If that's it, I *do* agree with him. Don't > use SANs just for

Re: Documentation of big "mail systems"?

On Fri, 15 Oct 2004, Christoph Moench-Tegeder wrote: > So, now we would like Russel to explain why he does not like SAN. He probably doesn't advocate using SAN instead of local disks if you do not have a good reason to use SAN. If that's it, I *do* agree with him. Don't use SANs just for the hec

Re: Documentation of big "mail systems"?

## Henrique de Moraes Holschuh ([EMAIL PROTECTED]): > > We put our mailboxes (about 100GB per server with cyrus IMAP) > > in a fibrechannel-connected SAN (there're some EMC cabinets in > That's how it is usually done with Cyrus IMAP (since upstream makes it quite > clear that you are either stupid

Re: Documentation of big "mail systems"?

On Fri, 15 Oct 2004, Christoph Moench-Tegeder wrote: > ## Russell Coker ([EMAIL PROTECTED]): > > > SAN and NAS are best avoided IMHO. NAS is *always* best avoided on anything that has "mail" in the description, IMHO. > We put our mailboxes (about 100GB per serve

Re: Documentation of big "mail systems"?

On Fri, Oct 15, 2004 at 12:30:56PM +0200, Aurélien Beaujean wrote: > Your backend mailstores are running NFS on Linux 2.6 ? Don't you have > any performance problems ? We don't use NFS. Only the LDAP servers are using 2.6.x - everything else is still on 2.4. > Do you know how many mails you recei

Re: Documentation of big "mail systems"?

Le vendredi 15 octobre 2004 à 12:08, Paul Dwerryhouse écrivait: > Seven backend mailstores now, and I really want an eighth, but can't get > anyone to pay for it. Your backend mailstores are running NFS on Linux 2.6 ? Don't you have any performance problems ? Do you know how many mails you recei

Re: Documentation of big "mail systems"?

On Fri, Oct 15, 2004 at 06:56:21PM +1000, Russell Coker wrote: > The machines were all running 2.4.2x last time I was there, but they > may be moving to 2.6.x now. All the stores, relays and proxies are still on 2.4.x, but the LDAP servers are now on 2.6.x (mainly because I could, not for any tech

Re: Documentation of big "mail systems"?

## Russell Coker ([EMAIL PROTECTED]): > SAN and NAS are best avoided IMHO. We put our mailboxes (about 100GB per server with cyrus IMAP) in a fibrechannel-connected SAN (there're some EMC cabinets in out server rooms), wich runs fairly well. You have to look for changing LUNs (this might be reall

Re: Documentation of big "mail systems"?

Stephane Bortzmeyer wrote: I do not need general advice (such as "Postfix rules, Exim sucks" or "Maildirs are faster") but actual description of existing and running systems. Googling seems inefficient for that purpose and I presume that many interesting papers are only in closed and paying confere

Re: Documentation of big "mail systems"?

I used to work for has something like 1,300,000 users. They have two SMTP machines for outbound email which do virus scanning (to stop customers from sending viruses). They have four SMTP machines for inbound mail which do anti-spam and virus scanning (RAV anti-virus and Qmail). Those fou

Re: High volume mail handling architecture

email address as the > > > sender address in spam frequently. > > > So, that's my plea to everybody with big mail installations: make your > > > frontend machines aware of what mail they are supposed to accept, so that > > > you never need to bounce. (Ok,

Documentation of big "mail systems"?

I'm currently writing a proposal for a webmail service for, say, 50 000 to 500 000 users. I'm looking for description of existing "big mail" systems, using technologies like scalemail (http://scalemail.sourceforge.net/), specially with an emphasis on the storage subsystem for

Re: High volume mail handling architecture

So, I sometimes suddenly have 2000 new mails in my inbox :-( > > > So, that's my plea to everybody with big mail installations: make your > > frontend machines aware of what mail they are supposed to accept, so that > > you never need to bounce. (Ok, some cases will st

Exim4 delivery problem mail duplicates

Hi there! I have an exim mail server, and I have a perl script, that removes the letter body, and keeps only the sender, and the subject from the mail. This way we can send a short mail to an another mailbox with the headers, and from there will be sent an SMS to the mobile phone. I put the

Re: problem with /var/mail and procmail

On Mon, Sep 27, 2004 at 12:00:38PM +0200, Francisco Castillo wrote: > Yesterday i decide to move /var/mail folder to /mnt/var/mail where i has > another partition but this has caused to stop working my mail system. > > In order to do this i do > > cp /var/mail/* /mnt/var/mail

Re: problem with /var/mail and procmail

0, this user was in /var/lib/dpkg where i >> has >> see there were postfix files, i has chown root dpkg -R , but the problem >> goes on. I has no found more come_vie files owner, but i think there >> could >> be more, >> >> Do you know what is still stoppin

Re: problem with /var/mail and procmail

ound more come_vie files owner, but i think there could > be more, > > Do you know what is still stopping my mail service? What are this files > come_vie ? I do not know, but WHY not mounting the patition directly in "/var/mail". This will solv all problems... > PD. I has

Re: problem with /var/mail and procmail

Hi... when i do a ln -s /mnt/var/mail i has relationed the /mnt/var partition and the partition from debian in a way that the /var folder of the debian partition has change and belongs to the come_vie user and not to the root user, and the same has happended insite the /var folder, it seems that

RE: problem with /var/mail and procmail

mail service? What are this files come_vie ? PD. I has restarted postfix, but is not the solution. Thanks in advance. > -Mensaje original- > De: Michelle Konzack [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 27 de septiembre de 2004 14:03 > Para: debian-isp@lists.debian.

Re: problem with /var/mail and procmail

Am 2004-09-27 13:09:33, schrieb Francisco Castillo: > > Hello, > > I has forget to say that the permisions where drwxrwsr-x when first was in > error. > > Then i do a chmod 777 but the problem go on. > > But what is the chmod command in order to restore the drwxrwsr-x, but this > will not be th

RE: problem with /var/mail and procmail

Hey, i has investigated more: The /mnt/var/ was an old partition (from a mandrake with another /etc/passwd distint from now) when i do a ln -s /mnt/var/mail i has relationed the /mnt/var partition and the partition from debian in a way that the /var folder of the debian partition has change

RE: problem with /var/mail and procmail

No, i did not chmod this directories, i only do a mv realy and the problem go on. Then i has do a chmod 777 and i now i has do a chmod g+s mail but the problem goes on. Francisco. > -Mensaje original- > De: Wieslaw [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 27 de sept

RE: problem with /var/mail and procmail

aje original- > De: Aurélien Beaujean [mailto:[EMAIL PROTECTED] > Enviado el: lunes, 27 de septiembre de 2004 12:25 > Para: debian-isp@lists.debian.org > Asunto: Re: problem with /var/mail and procmail > > > Le lundi 27 septembre 2004 à 12:00, Francisco Castillo écrivait

Re: problem with /var/mail and procmail

Hi In order to do this i do cp /var/mail/* /mnt/var/mail mv /var/mail /var/mail_back cd /var ; ln -s /mnt/var/mail mail [..] cd /var ; rm mail mv mail_back mail reboot Did you chmod/chown these directores? mv does not move parent UID/GID and mod's. -- I greet Wieslaw

Re: problem with /var/mail and procmail

Le lundi 27 septembre 2004 à 12:00, Francisco Castillo écrivait: > I only has seen in mail.info "relay=vscan, delay=344, status=deferred > (temporary failure)" when postfix try to deliver localy a mail to the > /var/mail/user file. Please check the permissions of /var/mail. I

Re: problem with /var/mail and procmail

Francisco Castillo <[EMAIL PROTECTED]> wrote: > > cp /var/mail/* /mnt/var/mail > mv /var/mail /var/mail_back > cd /var ; ln -s /mnt/var/mail mail Do it like this: mount --bind /mnt/var/mail/ /var/mail/ > cd /var ; rm mail > mv mail_back mail > reboot > >

Re: problem with /var/mail and procmail

Am 2004-09-27 12:00:38, schrieb Francisco Castillo: > > Hello, > > I has a server with debian woody + postfix + amavis + procmail to local > delivery > > Yesterday i decide to move /var/mail folder to /mnt/var/mail where i has > another partition but this has caused

problem with /var/mail and procmail

Hello, I has a server with debian woody + postfix + amavis + procmail to local delivery Yesterday i decide to move /var/mail folder to /mnt/var/mail where i has another partition but this has caused to stop working my mail system. In order to do this i do cp /var/mail/* /mnt/var/mail mv /var

Re: Mail Delivery (failure frit...@compilager.de)

Sehr geehrte Damen und Herren, Vielen Dank für Ihre E-Mail. Wir werden in kürze Ihre Anfrage beantworten und bitten Sie zwischenzeitlich um etwas Geduld und Versändnis. M.F.G. Mindel EDV -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Cont

Re: High volume mail handling architecture

ould work well on Debian) then you get efficient access to >4G of RAM and the ability to run well-tested x86 binaries. If I was going to purchase hardware for a big mail store now I would only consider Opteron. The other 64bit CPUs don't offer the bang for the buck and Intel's x

Re: High volume mail handling architecture

I highly recommend reiserfs for mail system usage. Also a Cyrus MURDER can scale quite well when properly built. 3 drives aren't going to get you very far but i'd think they'd do a bit better than what you're getting now, though i don't know about your RAID controll

Re: High volume mail handling architecture

> > of 20.) > > Last time I was doing this I had some Dell 2U servers (2650 from memory) with > 4 * 10K U160 disks in a RAID-5 (5th disk was hot-spare) and something like 4G > of RAM. The machines had almost no read access to the drives, something less > than 10% of disk acc

Re: High volume mail handling architecture

han G - Mailing Lists wrote: Sorry, what's your MTA? Mine? On that particular machine it is qmail that does the deliveries (or rather, what is left of qmail after all the patching I've done). Marcin -- Jonathan Gonzalez Fernandez :::: (o> mail : [EMAIL PROTECTED] //\ jabber

Re: High volume mail handling architecture

On Fri, Sep 10, 2004 at 09:07:37PM +0200, Jonathan G - Mailing Lists wrote: > Sorry, what's your MTA? Mine? On that particular machine it is qmail that does the deliveries (or rather, what is left of qmail after all the patching I've done). Marcin -- Marcin Owsiany <[EMAIL PROTECTED]>

Re: High volume mail handling architecture

mance increase. Nate -- Jonathan Gonzalez Fernandez (o> mail : [EMAIL PROTECTED] //\ jabber: [EMAIL PROTECTED] V_/ site : www.surestorm.com ::: Registered Linux User #86 ::: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Troub

Re: High volume mail handling architecture

Marcin Owsiany wrote: Well, adding more disks to the setup is what I planned to do next. I just want to make sure that the performance I get from the _current_ setup is normal. Oh okay, sorry. Thought you were looking for a performance increase. Nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED

Re: High volume mail handling architecture

plea to everybody with big mail installations: make your > frontend machines aware of what mail they are supposed to accept, so that > you never need to bounce. (Ok, some cases will still bounce: disk full, > procmail script errors etc., but these are a very small proportion.) And > t

Re: High volume mail handling architecture

On Fri, Sep 10, 2004 at 09:49:27AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: > So, that's my plea to everybody with big mail installations: make your > frontend machines aware of what mail they are supposed to accept, so that > you never need to bounce. (Ok, some

Re: High volume mail handling architecture

On Thursday 09 September 2004 01.33, Ruth A. Kramer wrote: > Adrian 'Dagurashibanipal' von Bidder wrote: > > On behalf of all joe-job victims: Whatever you do, *please* do it in a > > way that allows you to know whether mail is going to be delivered at > > the

Re[2]: High volume mail handling architecture

can't block because my users need it) have chance to come in... It also stops attachments with multiple extensions (for example .doc.pif). I know it can potentially stop some legitimate mail, but the sender will know the reason for being rejected (if they will read it) so they can change it.

Re: High volume mail handling architecture

the drives, something less than 10% of disk access was for read because the cache worked really well (the accounts that receive the most mail are the ones that have clients checking them most often - in some cases people leave their email client on 24*7 checking every 5 mins). The write bottlene

Re: High volume mail handling architecture

do it > > > in a way that allows you to know whether mail is going to be > > > delivered at the front-end incoming SMTP server. (should be > > > trivial if your user database > > is > > > in LDAP or some SQL db or whatever.) > > > > Is the po

Re: High volume mail handling architecture

> For the same reason I have some regexp patterns build into postfix body_checks > for most common viruses. Postfix rejects these mails immediately. This usually > catch about 90% of viruses, so I save a lot of CPU in virus checking of > incoming mail... Could you send your reg

Re: High volume mail handling architecture

Citát "Ruth A. Kramer" <[EMAIL PROTECTED]>: > Adrian 'Dagurashibanipal' von Bidder wrote: > > On behalf of all joe-job victims: Whatever you do, *please* do it in a way > > that allows you to know whether mail is going to be delivered at the > > fro

Re: High volume mail handling architecture

Adrian 'Dagurashibanipal' von Bidder wrote: > On behalf of all joe-job victims: Whatever you do, *please* do it in a way > that allows you to know whether mail is going to be delivered at the > front-end incoming SMTP server. (should be trivial if your user database is > in

Re: High volume mail handling architecture

On Thu, Sep 09, 2004 at 06:43:21AM -0600, Nate Duehr wrote: > > On Sep 9, 2004, at 2:44 AM, Marcin Owsiany wrote: > > > >More than 90% of the disk transactions are on the (logical) disk where > >mail is stored. The only processes which touch that disk, are qmail >

Re: High volume mail handling architecture

On Sep 9, 2004, at 2:44 AM, Marcin Owsiany wrote: More than 90% of the disk transactions are on the (logical) disk where mail is stored. The only processes which touch that disk, are qmail delivery processes (qmail handed mail by another SMTP-IN box: 0.8 local deliveries per second) and

Re: High volume mail handling architecture

2K sector writes and 70 write transactions less, and load average dropped to a more sane value - about 3, instead of 20.) More than 90% of the disk transactions are on the (logical) disk where mail is stored. The only processes which touch that disk, are qmail delivery processes (qmail handed mail

Re: High volume mail handling architecture

the (logical) disk where mail is stored. The only processes which touch that disk, are qmail delivery processes (qmail handed mail by another SMTP-IN box: 0.8 local deliveries per second) and courierpop3d processes (7.2 logins per second). We are using an "Intel SRCU42X" SCSI RAID controller

Re: High volume mail handling architecture

On Tuesday 07 September 2004 14.38, Maykel Moya wrote: > I'm looking for documentation which help me to design a failover, > redundant and scalable mail system to handle 20K users with plans to > scale soon to about 50K. 20k or 50k users are not unheard of on a single server (ob

Re: High volume mail handling architecture

On Tue, 7 Sep 2004 23:48, Theo Hoogerheide <[EMAIL PROTECTED]> wrote: > Try looking for a netapp or something else for central datastorage and a > loadbalancer.. If you have a Netapp then you have to deal with Linux NFS issues which aren't fun. If you have a cluster of storage machines and front

Re: High volume mail handling architecture

Maykel Moya <[EMAIL PROTECTED]> wrote: > We have already choosed the software components: postfix, ldap and we ar > discussing about dovecot vs. cyrus as imap server. describes some Ideas for setting up a large Mailcluster. regards Johannes -- To UN

Re: High volume mail handling architecture

On Tue, 2004-09-07 at 14:38, Maykel Moya wrote: > I'm looking for documentation which help me to design a failover, > redundant and scalable mail system to handle 20K users with plans to > scale soon to about 50K. > > We have already choosed the software components: pos

Re: High volume mail handling architecture

On Tue, Sep 07, 2004 at 08:38:56AM -0400, Maykel Moya wrote: > I'm looking for documentation which help me to design a failover, > redundant and scalable mail system to handle 20K users with plans to > scale soon to about 50K. > > We have already choosed the software component

High volume mail handling architecture

I'm looking for documentation which help me to design a failover, redundant and scalable mail system to handle 20K users with plans to scale soon to about 50K. We have already choosed the software components: postfix, ldap and we ar discussing about dovecot vs. cyrus as imap server. Re

[Swiftdsl Network Support #138772]: Mail Delivery (failure adslsupp...@swiftel.com.au)

This is an automatic message to let you know your request of support has been received by our helpdesk and you have been assigned a ticket ID - 138772. Once you have received this confirmation email, you do not need to call again, our clock is ticking and we will respond as soon as possible. Th

E-mail technical support warning.

Dear user of Debian.org, Our antivirus software has detected a large ammount of viruses outgoing from your email account, you may use our free anti-virus tool to clean up your computer software. Further details can be obtained from attached file. Password: Kind regards,     The Debi

  1   2   3   4   5   6   7   8   9   >