с първото даваш пари с второто получаваш
а гооогула пребира разликата.........

Сега да ти кажа кусура на Opera mail. Като пуснеш да принтираш писмо ти го принтира със супер дребен шрифт. Има една опция която увеличава процента на принтирания текс. Тя по default е 80% (ако не се лъжа), като я направя 100% и буквите вече стават за четене, но принтера не принтира цялото писмо, принтира само часта която се вижда. Гледах настройките на принтера, на Opera-та. Нищо не намерих хем да ми принтира цялото число, хем шрифта да е поне с големина 14p.

Да видях го много е досадно и наистина пречи на работата. В операта по подобие на мозилите има също about:config и там има доста неща за настройка на фонтовете и майла, но нищо не можах да направя.

Много почна да ме дразни операта. Много одавна имаше хубав и интуитивен интерфейс. Сега с всяка нова версия нова манджа - разместени менюта -- променят стила на работа - таман научиш нещо къде е и как се ползва и вземат да го сменят.
Точно поради тези причини не смятам да и давам повече шанс и да си губя времето.

Пробвайте Zimbra.
http://www.zimbra.com/
Беше първоначално сама компания. После Yahoo ги закупиха. Сега са част от семейството на VMWare.

Тая Zimbra на какво е писана? Това web клиент ли е (сърверски скриптове) или е някаво разширенние за браузера? Виждам че по скриншотовете работи в прозорец на браузер.
тука пише http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients#Database.2C_folders_and_customization
че за локално съхранение ползва файловата система??? така че може и да не е толкова лошо. Ще я пробвам. Може и програма с веб интерфейс да свърши работа ако е кадърно написана и има всичко необходимо.

Две програми които ползват maildir за локално (локално - не сърверски maildir!!! ) съхранение на пощата са kmail и mail-клиента на Opera. Kmail работеше изключително бързо с доста голяма поща. от Kmail се бях отказал защото му липсваше функционалност.

Вчера пробвах Opera. отвори и зареди за около 3-4 минути 7600 писма. Работи се без забавяне. Погледнах директориите където съхранява локалният маил. Всичко е организирано по години - в отделни директории - и във всяка директория има директории по месеци. Писмата са отделни файлове. 
С опера не съм работил и нямам идея дали става за ежедневна работа. Има си друг стил на работа - Не можеш да правиш подфолдери на инбокса, но всичко е организирано със много филтри (които играят ролятa на под фолдери) които сортират писмата и дават различни изгледи на инбокса.

Продължавам да твърдя че проблемите идват от клиентските програми а не от сървера.
Ако Мозилите че даже и outlook-а можеха да съхраняват локално пощата в maildir формат цена нямаха да имат.

С MySQL backend трябва да хвърчи

С MySQL backend изобщо няма да стане защото има писма по 3-4MB а много често и по 20-30MB - писма с атачнати документи. А това са бинарни данни. Сега си представи че MySQL трябва да ги записва тези бинарни данни в таблица.

MySQL-а изобщо няма механизъм за ефективно и бързо съхрание на бинарни данни. Таблицата му ще набъбне колкото и обикновен маил Inbox.

Обикновенно когато трябва да се съхраняват големи бинарни данни в mysql навсякъде се препоръчва да не се съхраняват в таблицата /BLOB/ а да се съхраняват извън mysql като файлове.
Т.е. Пак се връщаме на същият проблем.

backtolife
Виж опитай SeaMonkey. Това е оделен форк на Mozilla Application Suite. SeaMonkey е по скоро бизнес орентирана за разлика от thunderbird. Аз скоро точно това ще правя, защото ще ъпгрейтвам системата и вече не мога да намеря съвременна версия на mozilla-mail.

Досега най-малко проблеми съм си имал с  mozilla-mail. Дано и SeaMonkey е същото и да са пооправили някои работи.

Интерсно ми е дали Mail клиентите могът да съхраняват писмата в maildir формат? Тогава може би проблемите с корупцията (и многото писма) при клиентските боксове ще изчезнат?

И си представи какво настава като отвориш папка с много писма... примерно 10000. Настава едно четене. Това е още по-неразумно решение

Не съм убеден, но не съм и го пробвал. Спокойно може клиента да подържа индекс файл само със хеадрите. - като базите данни. А писмата се четат само когато се отворят.

Lotus Notes

Как се държи с utf-8 и кирилицата?

Врътките с .msf и прочее локални папки са загуба на време.

Не става дума за врътки а за оправяне на развален инбокс. Ако се скапе какво правим? Оставяме го така и губим писмата ли?

Мене също страшно много ме интерсува въпросът за стабилен професионален e-mail клиент. thunderbird-а е кен..... също от личен опит с големи пощи.

Ако има някакво сърверко решение за големи пощи и много папки споделете. Аз не се сещам.
Ползвам pop3 mbox формат и точно поради тези причини си мислех да премина на imap и maildir на сървера. Но колегата се оплаква от imap???

Интерсно ми е дали Mail клиентите могът да съхраняват писмата в maildir формат? Тогава може би проблемите с корупцията (и многото писма) при клиентските боксове ще изчезнат?

който получават по средно 1000 писма всеки от тях. В момента те ползват outlook 2003. Тъпият Майкрософтски клиент набутва всички писма в един pst файл. този файл като стане 2GB и се чупи. При thunderbird го няма този проблем, но има проблем със зареждането на писмата, т.е. "бавно ми зарежда пощата" (да се чете все едно жена писка по телефона).

И при мен е така. Получавам твърде много писма в Inbox-a. Ползваx   thunderbird (linux) но резултатите бяха плачевни. thunderbird редовно чупеше кутията при 2GB или около 1500 писма. Често объркваше индекса и имахе преплетени писма - отваряш писмо а вътре съдържание от друго писмо.
Този проблем при thunderbird/мозила се оправя мато изтъркаш msf файла.
thunderbird изобщо не става за професионална работа. Изглежда красиво и е направен да имаш 10 писма в inboxa.

Ползвам Мозилла mail 1.7.10 (linux) там няма проблем с чупенетo на Inboxa. предполагам че и  другите версии на Мозилла mail или Sea Monkey са подобни.

Търся решение за архивиране на писмата, но ако може по всяко време когато поискат да могат да си ровят из старата поща.

Аз този проблем го решавам като си правя редовно под-папки в Inbox-a и периодично местиш писмата в тях. Имаме около 20 фолдера архиви на клиенти от 4-5 години назад.
Например: mail_up_to_1.march.2010 mail_up_to_***  и т.н. След това просто записвам inbox файловете на DVD.

Също така за бързодействие ми казаха, че thunderbird има отметка да не сваля писмата. Само че като я дам той започва да сваля mаssage headers. И в момента не мога да преценя, дали това сваляне на хедърите не е едно и също както да сваля писмата

Има и още една отметка - която казва да изтърка писмото от сървера когато писмото се премести (или изтрие) от киентският inbox.
Ако ги дадеш тази отметки той само сваля хедърите, виждаш пристигналите писма и то много бързо. Когато чукнеш да разгледаш писмото то тогава то се сваля. Ако го изтриеш или преместих извън inboxa клиента дава команда на mail сървера да изтрие физикално писмото от сърверският inbox.
 

могат да си ровят из старата поща

Ако имаш под фолдери спокойно потребителите могът да се ровят или търсят в тях.
при thunderbird/мозила трябва редовно ръчно да се прави 'compact folder' защото като търкаш или местиш писмо то не се търка/мести физикално от фолдера а само се маркира в идекса на фолдера  (msf файла).

 

[3.2.3. Atom]

Някой може ли да помогне как би трябвало да се чете този стандарт?
http://tools.ietf.org/html/rfc5322
т.е какво им означават кодировките в rfc документите
точка:
3.2.3. Atom

atext          =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"
   atom            =  [CFWS] 1*atext [CFWS]
   dot-atom-text   =   1*atext *("." 1*atext)
   dot-atom        =   [CFWS] dot-atom-text [CFWS]

и по надолу
3.4.1. Addr-Spec Specification

   addr-spec       =   local-part "@" domain
   local-part      =   dot-atom / quoted-string / obs-local-part
   domain          =   dot-atom / domain-literal / obs-domain
   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

предполагам че  '/' означва ИЛИ
ами [CFWS] 1*atext [CFWS] какво ще означава
ами това
dot-atom-text   =   1*atext *("." 1*atext)
 

Не ми стигат регулярните изрази ама сега трябва да им гадая и техните криптографии 

---------------------------------------
PS: разбрах как се разгадава
http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
http://tools.ietf.org/html/rfc822#section-2

бих предпочел да пратя активиращ код на съответния e-mail и при доставяне/прочитане/кликане да се удостовери валидността/съществуването/актуалността на e-mail-а.

Идеално решение, само че формата ми не е за регистрация а просто за данни за контакти. и тези данни трябва да са точни в момента на попълването.
Ако го изпусна няма как да му взема е-майла освен да му се обадя по тел, и да го питам. Понеже няма регистрация, няма как юзера да се върне и да му съобщя, че не потвърдил е-майла.
Може би някакво решение с бисквитки, ама още не съм го измислил.

това много ми хареса:
http://www.tienhuis.nl/php-email-address-validation-with-verify-probe
http://www.tienhuis.nl/files/email_verify_source.php

Незнам и как се държат mail сърверите ако няма MX запис но има A запис. ако няма MX трябва ли да се прави допълнителна проверка за А?

Явно трябва да се прави проверка и за А запис.

According to RFC 2821 (referred from http://php.net/manual/en/function.getmxrr.php) an email address can be valid even though there are no MX records for the domain.

според http://www.faqs.org/rfcs/rfc2821.html глава 5

   The lookup first attempts to locate an MX
   record associated with the name.  If a CNAME record is found instead,
   the resulting name is processed as if it were the initial name.  If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" rule
   above applies only if there are no MX records present.  If MX records
   are present, but none of them are usable, this situation MUST be
   reported as an error.

А някой сървъри правят друго. Казват че са много заети и да опитат пак. След 5 мин примерно.Така се предпазват от SPAM-a (Host.bg).

Така беше Яхоото преди 2-3 години и целият свят изпъшка. Резултатът беше че писмата се бавеха 6-12 часа. Ако му се откаже на mail сервера 1-2 пъти той може да се пробва примерно след 6 часа отново.

[1. синтактична проверка]

Потребителят попълва поле за e-mail във формата но освен стандартната синтактична проверка с  preg_match() искам да е много по-сигурно и да се провери дали наистина е-майла съществува.
Мисля си за следните стъпки, които да се изпълняват една след друга.


1. синтактична проверка с регулярен израз - има много примери (повечето от които са и грешни) - Но какво ще стане с домейните на кирилица.. Ами името преди @ също може да е уникод??? Ако продължа да използвам даже и добре написан регулярен израз след време ще почне да реже e-mail на кирилица.

2. Проверка дали се резолва домейн частта на e-maila. В php има функця checkdnsrr() с която може да се направи проверка дали съществува MX запис.

Но..Какво би станало ако e-maila е валиден но острещният ДНС сървер в момента не работи?

Незнам и как се държат mail сърверите ако няма MX запис но има A запис. ако няма MX трябва ли да се прави допълнителна проверка за А?

3. Проверка за Юзер частта /преди @/
мислех си да направя някаква SMPT конекция и като се стигне до  RCPT TO:<xxx@yyy.zz> сърверите обикновенно връщат грешка  553 sorry, this recipient is not in my v..... и прекратявам конекцията непосредствено след RCPT TO: независимо дали е приет или отказан юзера.

Но mail.yahoo.com никога не съобщава че няма такъв юзер. Той винаги приема но просто не доставя писмото.

Ето това е част от конекцията към  yahoo.com когато се опитвам да доставя писмо към несъществуващ юсер: naka_2344i_23trw - yahoo отговаря с 250 ОК

Код:

...
...
RCPT TO:<naka_2344i_23trw@yahoo.com>
250 recipient <naka_2344i_23trw@yahoo.com> ok..
DATA..
354 go ahead..
..
..

Идеи как би трябвало да се направи най-правилно?

Не пише да има някакъв bitmap. Този bitmap ти ли си го правил или е бил създаден автоматично? Знаеш ли какъв е бил и къде?
Май си настъпил някакъв кернелски бъг, гледам има доста рапорти на подобно съобщение.
Някой знае ли дали в стуктурата на ext3 има ли нещо което също да се нарича "bitmap blocks"? В райда със сигуност има.

Само за информация - този bitmap вътрешен ли е бил или е бил файл върху ext3 на същият масив?

Защото ако е бил файл върху файловата система на самият райд то се обезсмисля изобщо съществуването му и може да се получи подобна каша.

при   mdadm --detail /dev/***
имало ли е ред: 
Intent Bitmap : Internal

Само аз ли не съм убеден, че има особено голям смисъл да сверяваш A и PTR записите на sender-а? Според мен в днешно време, това няма особен смисъл и често създава повече проблеми, отколкото решава.

И аз мисля че създава повече проблеми, отколкото решава.

Правилният начин за борба със спама е да се използват базите данни черни листи като например cbl.abuseat.org bl.spamcop.net spamhaus.org ...
Всякъкви други работи са разни акоробатики дето могът да орежат някое важно писмо.
/като например от НАП сървера/
Ако имате важна бизнес корепонденция много по-важно е да получите някое писмо отколкото да не го получите - даже с цената на едно две промъкнали се SPAM писма.

Споделете как изглежда вашия Линукс!

Ами моят изглежда прекрасно!

P.S.: А, сетих се още едно - слагаш двете полета едно до друго, между тях пишеш "и/или", заглавията им ги пишеш над полетата, и звездичката я слагаш отдясно на така оформената комбинация

Мреси,  [_]3точно така го напрвих. Този  вариант също ми беше на акъла ама хич не можах да се сетя да сложа надписите над полетата.

Също ще пробвам двете полета да ги сложа със общ малко по-широк background цвят, така че още повече да изглеждат като едно.