شيما دهباشي

Smarter and outgoing blocking

شیما دهباشی — Wed, 12 Mar 2008 17:26:00 GMT

Have you ever tried to use outgoing blocking in Smarter 4.x ? It's new feature in Smatermail which helps you to control the outgoing emails. As you know, smarter uses different weights in order to calculate the final score of an email. I selected checking SPF record for outgoing emails. After it I could send any email by using outlook and webmail! And I had to use webmail on server!! Checking logs shows this error :
Fail - Senders IP is NOT valid for senders domain (weight : 30)
I changed SPF record in zone file and it didn't work ! Finally I found that mail server checkes my primary IP and when I use outlook to send email, SPF checker detect my IP and I can't send email at all! Now the question why SmarterMail uses SPF checking for outgoing email s blocking, with knowing this point.

Receiving "Specified file is not accessible " during Plesk backup

شیما دهباشی — Tue, 12 Feb 2008 17:20:00 GMT

Receiving "Specified file is not accessible " during Plesk backup
In Plesk linux (8.3) We received tones of emails with this content :
Subject : Error is occured during scheduled backup
Body :
Client: yourclient
Plesk entry point: https://domain.com:8443/
Following error is occured during scheduled backup process:
Specified file is not accessible

Since the file was not specified, I couldn't find the problem. After checking the processes in server I found thousands of this process :
/usr/bin/python2.4 /usr/local/psa/admin/sbin/agent_runner /var/lib/psa/dumps

To solve the problem, proper permission should be set for tmp and dumps folder :
drwx------ psaadm psaadm tmp
drwxr-xr-x psaadm psaadm dumps

Changing Server collation - Sql Server

شیما دهباشی — Sun, 04 Nov 2007 14:13:00 GMT

If you want to change default collation of Sql Server :

1-Make sure you have all the information or scripts needed to re-create your user databases and all the objects in them.
2-Eport all your data using a tool such as bulk copy.
3-Drop all the user databases.
4-Rebuild the master database specifying the new collation in the SQLCOLLATION property of the setup command. For example:

start /wait setup.exe /qb INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=<SA Password> SQLCOLLATION=SQL_Latin1_General_CP1_CI_AI

Mailenable Pro : another note!

شیما دهباشی — Wed, 20 Jun 2007 19:37:00 GMT

In previous posts I wrote about installing Mailenable and Mailenable Pro in same folder, today I found that If you are not sure about using Pro version of Mailenable it's highly recommended to install it in another folder :D ! Because If you want to uninstall it you will lose Mailenable at all!

Anyway, After removing Mailenable Pro, I couldn't use mailenable. I couldn't uninstall it byusing control panel and changin Plesk . Even reconfiguring Plesk doesn't help me to remove Mailenable standard edition! Mailenable wasn't available as a service in Plesk, and in component management, Plesk shows that mailenabe standard edition is not installed, but I had has not been removed completely and didn't work correctly.

Solution : At the end I used Mailenable uninstall procedure. It completely removed Mailenable ( I used install.log which was available in Mailenable folder) Then I removed all Mailserver components (webmail,mailenable,spamassassin,..) from plesk and installed them all again!

CGI error in Horde!

شیما دهباشی — Wed, 20 Jun 2007 19:24:00 GMT

Today we installed Plesk 8.1 on Windows server R2. everything was ok EXCEPT Horde webmail! When I requested for horde webmail I received:

CGI Error-The specified CGI application misbehaved by not returning a complete set of HTTP headers

I didn't find any reason for it! Everything was ok. All permissions and configuration. At the end I just look at php.ini and replace it with another horde's php.ini and it solved our big problem! I should mention that when I reconfigured webmail with these two commands:
"%plesk_bin%\websrvmng.exe" --reconfigure-webmail
"%plesk_bin%\defpackagemng.exe" --fix --type=webmail
I received the error again anad again!

Some notes about Installing MailEnable Pro

شیما دهباشی — Wed, 20 Jun 2007 18:47:00 GMT

It's really recommended to use Mailenable Pro instead of Mailenable standard Edition. There are many advantages for both users and administrators. Although we've heard that installing Mailenable pro with Plesk could be very difficult and at the same time risky, but we found it easy and beneficial!

First of all remember these notes:

It's recommended to install Mailenable pro, in the same folder with Mailenable.
After installing, you'll find that you can't add new email by using Plesk.
After installing all Mailenable ALL postoffices will be lost!

We wanted to install Mailenable pro in webmail, but it's possible to install Mailenablewebmail and mailadmin in to different websites. (You can select it during installation process). If the login page of Mailenable loads correctly but the labels have not been filled with correct strings, and you have already used Horde as a webmail, you should change application pool from plesk App to Mailenable App.

Besides, it's crystal clear that you must change webmail Content directory to Pleskdirectory\Mailenable\Bin\NETWebMail (if you wat to use .Net version of Mailenable webmail). It seems that psaserv and psacln should have read& execute permission in new installed webmail.

I should mention that after installing Mailenable pro you should reconfigure it, because there is no postoffice in mailenable administration panel ! Thanks to plesk you can use "%plesk_bin%\mchk.exe" --domain --domain-name=yourdomain
to add domain to the postoffice and add all emails that have been already created in Plesk.

Good to know :

1- In services section of Mailenable Pro, you'll find new services such as webmail. You can configure webmail in this section. for example : date and time , default encoding,... . You can remove default webmail or install it in new website!
2- you can login to webadmin if you have enough privilege. Inorder to make a user webadmin , just right click on post office and in web admin section, enable web administration section for post office. After that open users section of post office and make the user "admin".

domainkey

شیما دهباشی — Thu, 07 Jun 2007 17:59:00 GMT

افزودن امکان domainkey به SmarterMail

کاربران به ایمیلهای ارسال شده از شرکتهای معتبر و دامنه های مشهور اعتماد می کنند و همواره یکی از معمول ترین انواع spam ارسال ایمیل ساختگی تحت نام و یا دامنه های چنین شرکتهایی است . برای جلوگیری از این مساله و اطمینان از اینکه ایمیل های ارسالی حتما از طرف شرکت مورد نظر ارسال شده است می توان روشی تحت عنوان domainkey را مورد استفاده قرار داد.

در این روش برای هر دامنه یک Private key (کلید اختصاصی) و یک Public key (کلید عمومی) در نظر گرفته می شود. کلید اختصاصی هر دامنه در در اختیار mail server ارسال کننده ایمیل قرار داده شده و کلید عمومی از طریق DNS در اختیار عموم قرار داده می شود. ( قسمت A)

در هنگامی که یکی از کاربران تایید شده دامنه ایمیلی از طریق میل سرور ارسال می کند ، میل سرور با استفاده از کلید اختصاصی دامنه ، یک امضای دیجیتال ایجاد کرده و به header ایمیل اضافه می کند. سپس نامه را به میل سرور گیرنده ارسال می کند. (قسمت B)

میل سرور گیرنده پس از دریافت ایمیل ، امضای ارسال شده و دامنه فرستنده را شناسایی می کند . سپس از روی نام دامنه ، کلید عمومی دامنه را از DNS آن درخواست می کند. ( قسمت C )

با استفاده از کلید عمومی دریافت شده می توان به این نتیجه رسید که آیا امضای دیجیتال با استفاده از همان کلید اختصاصی دامنه ایجاد شده است یا خیر. در انتها میل سرور گیرنده ، ایمیل ارسالی را به مقصد تحویل می دهد. (قسمت D)

برای فعال کردن domainkey در SmarterMail می توانید برنامه DKeyEvent SM 0.2.7 را دریافت کنید. نحوه نصب برنامه در لینک قابل مشاهده است.

در هنگام نصب توجه داشته باشید که میل سرور شما برای 13-15 ثانیه ، متوقف خواهد شد. پس از نصب شما می توانید یک کلید عمومی و یک کلید اختصاصی برای دامنه مورد نظر خود ایجاد کنید.

این امکان وجود دارد که بخشهای مختلف سازمان شما از میل سرور های متفاوتی استفاده کنند. شما می توانید برای هر بخش یک جفت کلید تعریف کرد و اطلاعات مربوط به DNS دامنه را بر حسب بخشهای مختلف مرتب نمایید.

به عنوان مثال سازمان شما برای بخش روابط عمومی از میل سروری خاص استفاده می کند. بنابراین شما با استفاده از نرم افزار یک selector با نام publicrel ایجاد می کنید. کلید اختصاصی برای این selector ایجاد شده و در سرور ذخیره می گردد. سپس شما یک txt رکورد به صورت زیر به zonefile اصلی دامنه خود اضافه کنید :

publicrel._domainkey.yourdomain.com. IN txt ("p=ahdque68cbmnbc....")

این رکورد به عنوان کلید عمومی شما در اختیار تمامی میل سرور ها قرار داده خواهد شد.

افزودن امکان domainkey به Plesk 7.6

در صورتی که از کنترل پنل Plesk استفاده می کنید، نمی توانید رکورد مورد نظر را به دامنه خود اضافه کنید . به همین منظور مراحل زیر را طی کنید :

1- از table دامنه های plesk شماره مربوط به zonefile دامنه خود را به دست آورید :

select dns_zone_id from domains where name='yourdomain.com';

رکوردی به صورت زیر به فایل آن اضافه کنید :

insert into dns_recs(type,host,val,opt,time_stamp,dns_zone_id,displayHost,displayVal)
values('txt','yourselector._domainkey.yourdomain.com.','yourkey','','2007-05-1609:06:50',your dns_zone_id ,'yourselector._domainkey.yourdomain.com.','yourkey')

2- از طریق plesk ، اطلاعات مربوط به DNS دامنه را چک کنید. ( در نظر داشته باشید که بهتر است یکی از رکورد های موجود را ویرایش کنید تا فایل مجددا نوشته شود )
3- zonefile دامنه را چک کنید و از درستی آن مطمئن شوید.
4- درستی رکورد جدید را با استفاده از این لینک چک کنید.
5- با استفاده از دستور dkeyevent.exe -diagnose local_email_address وضعیت دامنه را چک کنید.
6- یا ارسال یک ایمیل از دامنه مورد نظر به Yahoo و یا به از طریق این لینک از درستی نصب domainkey اطمینان حاصل کنید.

به خاطر داشته باشید که افزودن یک کلید عمومی ثابت برای تمامی دامنه های سرور امکان پذیر نیست و شما نمی توانید که یک کلید ثابت را با استفاده از DNS Template موجود در Plesk اختصاص دهید.

برای اطلاعات بیشتر در مورد domainkey به سایتهای زیر مراجعه کنید :

http://domainkeys.sourceforge.net/
http://antispam.yahoo.com/domainkeys
http://forums.smartertools.com/forums/15443/ShowPost.aspx
http://smartermail.exhalus.net/domainkeys/dkeyevent_sm.chm

نقدی بر سیاستهای NIC و بازار آشفته دامنه ir

شیما دهباشی — Sun, 03 Dec 2006 18:33:00 GMT

NIC یا مرکز ثبت دامنه از طرف پژوهشگاه دانش های بنیادی، تنها ارائه دهنده دامنه های ir در کشوراست و متقاضیان این نوع دامنه می توانند از طریق مراجعه به کارگزاران دامنه های .ir (reseller های تایید شده ازسوی NIC ) و یا مستقیما و از طریق مراجعه به پایگاه اطلاع رسانی NIC دامنه ir خریداری کنند . مهمترین نکته ای که همواره نظر متقاضیان دامنه ir را جلب می کند، قیمت های متفاوتی است که کارگزاران دامنه های ir به مشتریان ارائه می دهند. بهتر دیدیم که به بررسی علل این تفاوت قیمت ، تاثیر آن بر بازار دامنه ir و نهایتا تاثیر آن بر وضعیت کارگزاران NIC بپردازیم.

تفاوت قیمت ناشی از چیست ؟

دامنه های ir با یک قیمت پایه 12800 تومان ( معادل دو واحد ) برای یکسال به فروش می رسد. این نوع دامنه بر حسب تعداد واحدی که NIC به آنها اختصاص داده است مبادله می شود. به عنوان مثال برای خرید دامنه ir شما 2 واحد پرداخت می کنید. هر واحد به طور پیش فرض 6400 تومان است اما هر کارگزار این واحد را با تخفیفی متفاوت و بر حسب اعتبار خود نزد NIC ، خریداری می کند.

با توجه به هزینه هایی که مراجعه مستقیم متقاضیان به NIC تحمیل می کرد، این مرکز فروش دامنه های خود را با درصد تخفیفی مشخص به کارگزارانش واگذار کرده است . این تخفیف که از روشی با عنوان Quantitative Discount پیروی می کند به گونه ای است که کارگزار در ابتدا یک تعداد واحد دامنه از NIC خریداری می کند و سپس آن را در مدت شش ماه به مشتریان خود می فروشد . هرچه تعداد واحدهای خریداری شده بیشتر باشد ، NIC واحد را با قیمت کمتری به کارگزار می فروشد. حداقل تعداد خرید اولیه مشخص است . هر کارگزار باید حداقل 125 واحد خریداری کند . بنابراین قیمت پایه دامنه .ir برای کارگزاران 9600 تومان خواهد بود . بهتر است به جدول 1 توجه کنید . طبق این جدول حداقل قیمت واحد 1600 تومان ( قیمت دامنه 3200 تومان ) است . به عبارت دیگر به احتمال زیاد حداکثرهزینه ای که هر واحد برای NIC در بردارد برابر 1600 تومان باید باشد .

قیمت واحد تومان	قیمت پایه دامنه تومان	درصد تخفیف	تعداد واحد
4800	9600	25	125
4736	9472	26	149
4608	9216	28	173
...	…	…	…
1600	3200	75	3375

جدول 1- نحوه محاسبه تخفیف

بنابراین هر کارگزار بر حسب تعداد واحد خریداری شده ، قیمت مورد نظر خود را برای دامنه ir پیشنهاد می کند . شاید بگوییم این " رسم بازار " است . مقایسه قیمت های کارگزاران – و حتی فروشندگانی که اسامی آنها در فهرست NIC نیست – نشان از این دارد که سیستم قیمت گزاری صحیح نیست. نمودار 1 را ببینید . در این جدول به بررسی قیمت های ارائه شده برای دامنه ir از سوی چند فروشنده و نه لزوما کارگزار پرداختیم .

نمودار 1- قیمت دامنه های .ir بر حسب قیمت ارائه شده در وب سایت فروشنده . تاریخ : 10/9/85

قیمتها نشان می دهد که این بازار هرچه باشد سالم نیست! آیا این امکان وجود دارد که شرکتی پایین ترین قیمت بازار را در اختیار دارد ، بازهم بیشترین ضرر را پرداخت کند ؟! شاید این کارگزار از ضرر بیشتری فرار می کند. فراری که به ضرر تمامی کارگزاران و به سود خریداران تمام خواهد شد. البته واقعا نمی دانیم که شرکتهای دیگر نیز در حال فروش دامنه ها کمتر از قیمت واقعی آن هستند یا خیر اما مطمئن بسیاری ضررهایی به خاطر دامنه ir پرداخت می کنند.

آیا NIC روش درستی در قبال کارگزاران خود پیش گرفته است ؟

می دانیم که NIC تنها مرکز فروشنده دامنه ir در کشور می باشد ، بنابراین هیچ رقیبی در کشور وجود ندارد تا NIC نگران از دست دادن سهمش از بازار و یا قیمتهای رقیبانش باشد . از طرف دیگر ، کارگزاران منطقا نمایندگان NIC هستند تا استفاده از دامنه ir را در سطح کشور توسعه دهند. هیچ یک از کارگزاران ارزش افزوده ای بر دامنه ای که می فروشند ندارند و دقیقا همان چیزی را عرضه می کنند که NIC در اختیار آنها قرار داده است .

روشی که NIC پیش گرفته است (Quantitative Discount)، روشی استاندارد است. در این روش که در بیشتر موارد توسط تولیدکنندگان مورد استفاده قرار می گیرد، تولید کنندگان برای کاهش هزینه های متغیر خود، سعی می کنند مشتریان را به سمت سفارش های عمده سوق دهند تا بتوانند خط تولید خود را برای مدت زمانی مشخص فعال نگاه دارند ، هزینه تولید هر واحد از محصول خود را کاهش دهند، هزینه حمل و نقل محصول به انبار مشتری را به حداقل برسانند، هزینه سفارش های پی در پی مشتری در طول سال را کاهش دهند و... اما آیا NIC یک تولید کننده است که با سفارش عمده مشتریان خود، هزینه تمام شده هر واحد را کاهش دهد و یا اینکه با هزینه هایی نظیر حمل و نقل محصول روبه رو است که با فروش عمده ، این هزینه ها را کاهش می دهد؟ درست است که با این روش :

1- NIC هزینه مراجعه مستقیم متقاضیان به مرکز خود را به صفر رسانده و این هزینه به کارگزاران خود تحمیل می کند. (در حقیقت مرکز ثبت دامنه 50 Call center - یا همان کارگزار! – در سطح کشور دارد که تمامی هزینه های مربوط به پشتیبانی مشتری های NIC را تحمل می کنند )

2- هزینه های ناشی از سفارش های شش ماه کارگزاران را کم می کند ( NIC تنها در دو مورد در شش ماه با نماینده مالی کارگزار وارد مذاکره می شود : 1- تمدید قرارداد 2- افزایش تعداد واحد.)

3- با ارائه تخفیف از کارگزاران خود حمایت می کند.

4- با ارائه تخفیف با درصد بالا ، از کارگزاران عمده خود حمایت می کند.

اما پرسشی که باید پاسخ داده شود این است که آیا روش فوق به درستی اجرا می شود و آیا برای کارگزاران نیز مفید است یا خیر؟ با رجوع به قوانین حاکم بر رابطه NIC و کارگزار می توانیم به پاسخ بهتری برسیم :

تعداد واحدهایی که در اختیار کارگزار قرار می گیرد ، باید در یک محدوده زمانی 6 ماه فروخته شود. اگر کارگزار در پایان زمان قراردادش موفق به فروش تمامی واحدهای ذکر شده در قرارداد نشود ،اعتبار باقی مانده توسط NIC ضبط خواهد شد. به عبارت بهتر مبلغ اولیه ای که در اختیار NIC قرار می گیرد، قابل عودت به کارگزار نخواهد بود.

با توجه به قانون فوق NIC هیچ زمان متحمل ضرری نخواهد شد. هر اتفاقی که در بازار کوچک دامنه ir روی دهد ، هیچ اهمیتی برای NIC نخواهد داشت. منشا این اتفاقات می تواند یکی از موارد زیر باشد :

تصمیمات نادرست NIC
اشتباه در خط مشی قیمت گذاری یک کارگزار
شکستن قیمت توسط کارگزاران برای حفظ سرمایه درخطرشان
شکستن قیمت توسط شرکت های تازه وارد
شکستن قیمت توسط شرکتهایی با سرمایه بالاتر

حال با یک مثال ساده می توانیم دلیل وضعیت بی ثبات قیمت دامنه .ir و تاثیر تصمیمات NIC را ببینیم :

- شرکت r1,r2,r3 کارگزاران NIC هستند که دامنه را با قیمت 9700 تومان وبا حداقل سود می فروشند.

- شرکت r1 افزایش اعتبار می دهد و با استفاده از سیستم تخفیف NIC هر دامنه با قیمت 8576 تومان خریداری کرده و به قیمت 9000 تومان به فروش می رساند.

- شرکت r4 با قرار دادی تازه وارد بازار می شود و هر دامنه را 5000 تومان خریداری کرده و با قیمت 7000 تومان به فروش می رساند تا به ازای هر دامنه 2000 تومان سود داشته باشد.

- شرکت r5 با قرار دادی تازه وارد بازار می شود و هر دامنه را 5000 تومان خریداری کرده و با قیمت 5200 تومان به فروش می رساند تا بتواند مقدار کم سود خود را با تعداد زیاد فروش جبران کند.

- شرکت r6 که هر دامنه را با قیمت 7000 تومان خریداری کرده و با قیمت 7500 می فروخته است با توجه به پایان قرار داد و برای جلوگیری از هدر رفتن سرمایه ای که در اختیار NIC دارد، باقیمانده اعتبار خود را با قیمت بسیار پایین مثلا 3000 تومان به فروش می رساند !

در انتها : شرکتها r2,r3 به احتمال فراوان درصدی از اعتبار اولیه خود را به NIC واگذار خواهند کرد. شرکت r1 در صورت تمدید قرار داد ، می تواند مازاد قرارداد قبلی را در قرار داد بعدی مورد استفاده قرار دهد و...

تجربه نشان می دهد که قیمت دامنه .ir زمینه ساز فروش دامنه با پسوندهای دیگر و حتی فروش میزبانی می باشد و با تمام کوچکی بازار و در عین حال سود کم آن ، بازهم به عنوان بخشی که نمی توان از آن چشم پوشی کرد مطرح می شود. در بسیاری موارد حتی دیده می شود که اگر متقاضی دامنه .ir درخواست سرویس میزبانی نیز داشته باشد ، می تواند دامنه .ir را با تخفیف خوبی از کارگزار خریداری کند! کم نیستند فروشندگانی که قیمتی متغیر برای دامنه .ir تعیین می کنند و ضررهای دامنه .ir را با استفاده از قیمت های سرویس میزبانی خود جبران می کنند تا حداقل با این ترفند بتوانند تعدادی از واحدهای خریداری شده از NIC را در حالتی به فروش برسانند که ضرر کمتری برایشان داشته باشد.

در حقیقت در این میان تمامی ضررها متوجه کارگزاران است . کارگزارانی که به یکباره با کاهش شدید تقاضا مواجه می شوند و دلیل آن را در شکسته شدن قیمت توسط یک کارگزار دیگر پیدا می کنند، در حالی که همگی نماینده یک شرکتند و مطمئنا شرکت اصلی باید این بازار را کنترل کند.

درست است که NIC با توجه به روش مورد استفاده خود ، هیچ کارگزاری را محدود به قیمتی خاص نمی کند و یا اینکه لزوما هیچ شرکتی را تهدید به عدم تمدید قرار داد نمی کند ، اما روش اجرای سیستم تخفیف NIC ، به گونه ای است که در بلند مدت شرکتهای کوچک خود درخواست تمدید قرارداد به NIC نخواهند داد و قیمت نیز به سمت قیمت اصلی که از سوی 2-3 کارگزار ارائه می شود ، متمایل خواهد بود. به عبارت بهتر NIC خواسته یا ناخواسته بازار را به سمت قیمت ثابت و مورد نظر خود پیش می برد. در این حالت قیمتی پایین تر از قیمت واقعی از سوی کارگزاران عمده بر بازار حاکم شود و کارگزاران کوچک عملا شرایط رقابت را از دست می دهند.

در نظر داشته باشیم :

1- همه تولیدکنندگان و عمده فروشان می توانند قیمت پایه خود را به کارگزاران خود اعلام کنند – البته به شرط حفظ تمامی اصول اخلاقی بازار از دو سوی طرف قرارداد . نظیرحفظ قیمت از سوی کارگزار برای حفظ حقوق کارگزاران دیگر و کنترل قیمت از سوی تولید کننده برای حفظ قیمت در وضعیتی که تمامی کارگزاران بتوانند در بازار رقابت باقی بمانند و یا اینکه حداقل به واسطه تصمیم دیگران سرمایه خود را از دست ندهند . خصوصا زمانی که NIC نگرانی هیچ شرکت رقیبی را ندارد ، می تواند با تعیین حداقل و حداکثر قیمت کمی بر کارهای خود نظارت داشته باشد. به هر صورت زمانی که یک مرکز تحقیقاتی وارد بازار خرید و فروش می شود و حتی سعی می کند با فعال کردن کارگزاران و تخفیف های متعدد بازار دامنه .ir را گرم کند ، بد نیست خود نظارت آن را بر عهده بگیرد زیرا که هیچ مرجعی نیست که در این بخش نظارت کند.

2- ورود نسل جدید کارگزاران NIC که در حقیقت تعداد محدودی شرکت خصوصی هستند که قانونا دارای تمامی حقوق NIC هستند و دامنه های .ir معادل یک سوم قیمت های NIC در اختیار مشتریان حقیقی و حقوقی قرار می دهند ، بحث دیگری است که این بار نه تنها کارگزاران کوچک بلکه کارگزاران عمده NIC را نیز تحت تاثیر قرار می دهد. در حالیکه کارگزاران عمده NIC با قرار دادن سرمایه ای بیش از 4 میلیون تومان نزد NIC سعی در کاهش قیمت و حتی ثابت نگاه داشتن آن دارند ، اما این کارگزان خصوصی جدید ، این امکان را به تمامی شرکتهای تازه وارد و افراد حقوقی می دهند تا با هزینه ای بسیار کم، در حدود 600 هزار تومان ، دامنه .ir با قیمت 4000 تومان عرضه کنند! اینکه منشا این سیاست از کجاست ، فلسفه وجودی کارگزاران جدید NIC با وجود کارگزاران فعلی NIC چیست ، اطلاع رسانی راجع به خصوصی سازیNIC چه زمانی صورت گرفته است و یا اینکه اطلاع رسانی در مورد وجود این کارگزاران جدید چگونه انجام پذیرفته است، پرسش هایی هستند که پاسخ آنها را تنها NIC می داند و بس!

3- در هنگامی که حداقل و حداکثر قیمت و حاشیه سود برای کارگزاران تعریف نشده است و هر کارگزار از قانون خود پیروی می کند ، صحبت از کارگزار فعال کردن بی انصافی است . در جامعه حساس به قیمت ما ، فعال بودن در بسیاری موارد با عرضه پایین ترین قیمت معادل است.

4- اگر قرار است که سیستم تخفیف پا برجا بماند باید هدف آن مشخص گردد : اگر هدف این است که کارگزاران عمده در صحنه باقی بمانند و کارگزاران کوچک – خواسته یا ناخواسته – از صحنه خارج شوند ، بهتر است NIC صراحتا این مساله را اعلام کند. زیرا که با وجود کارگزارانی که بسیار متفاوت رفتار می کنند، عملا شانس کارگزاران کوچک بسیار کم است . با وجود اینکه این مساله در قرار داد NIC و کارگزار قید می گردد که تمدید قرار منوط به عملکرد کارگزار می باشد، اما زمانی که NIC با روشهای عجیب خود جایی برای کارگزاران کوچک نمی گذارد ، بهتر است که از همان ابتدا حداقل مبلغ واریزی را برای کارگزار عمده قرار دهد تا هیچ کارگزار کوچکی به وجود نیاید یا اینکه درصد تخفیف خود به گونه معقول قرار دهد تا هیچ کارگزار عمده ای به وجود نیاید.

5- تفاوت قیمت بسیار زیاد در بین کارگزاران نه تنها باعث کاهش فروش می شود بلکه باعث سلب اعتماد مشتریان از کارگزان کوچکی می شود که قیمتهای واقعی .ir را رعایت می کنند . بعید نیست این کارگزاران کوچک که سود بسیار کمی دارند به زیاده خواهی متهم شوند .

6- به خوبی واضح است که با روش فعلی NIC ، سو استفاده فروشندگان از کارگزار عمده به سهولت صورت می گیرد و همین مساله باعث آشفته شدن ، بازار .ir می شود . حتی اگر اسم این مساله را سو استفاده نگذاریم ، باید بگوییم که کارگزاران می توانند کارگزارانی داشته باشند که این گروه نیز به اندازه کافی مشکلات اساسی برای کارگزاران کوچک ایجاد می کنند.

7- جالبترین نکته زمانی است که کارگزار پس از یک دوره موفق با افزایش اعتبار خود ، موفق به پایین آوردن قیمت برای مشتریان شده است. این کارگزار پس از پایان قراردادش مطمئنا و به اجبار به نقطه صفر از نظر NIC بر می گردد و مجبور است دوباره دامنه را با 25 در صد تخفیف به فروش برساند ! کارگزاران نمی توانند به عنوان کارگزاران با سابقه قیمت های خود را افزایش دهند ، در عین حال نمی خواهند برای فروش هر دامنه ضرر دهند! پس ترجیح می دهند که فروش دامنه .ir را از اولویت های خود خارج کنند. آیا از نظر NIC یک کارگزار با سابقه که در طولانی مدت رابطه خود را با این مرکز حفظ کرده و در توسعه بازار NIC همکار آن بوده است ، ارزشی دارد ؟ مسلما خیر.

8- به عنوان الگو بد نیست که به شرکت دیگر جهان در زمینه دامنه نظیر Tucows و دیگران نگاه کنیم. شرکتهایی که تخفیف و امتیاز تشویقی را بی معنی دانسته و همواره قیمت ثابتی را برای همه کارگزاران خود تعیین می کنند . البته شاید به این دلیل که در دنیای امروز شرکتهای بزرگ برای کارگزاران خود ارزش قائل هستند و کارگزاران فعال خود را عاملی برای توسعه و حفظ بازار خود می دانند. اما در محیط تک قطبی و بدون ضرر NIC ، تاثیر کارگزار بسیارکم است .

نصب GD در سرور لینوکس

شیما دهباشی — Tue, 15 Aug 2006 09:49:00 GMT

GD ،کتابخانه ای است که برای ایجاد تصاویر داینامیک مورد استفاده قرار می گیرد و به طور پیش فرض هم در PHP 4.3.x وجود دارد . برای نصب GD به صورت زیر عمل کنید :

1- برای کنترل وضعیت GD از ()phpinfo استفاده کنید. (در صورتی که GD روی سرور فعال باشد ، بخشی تحت عنوان GD رو در خروجی ()phpinfo می بینید . )
2- کتابخانه های مربوط به فرمت مورد نیاز خود را نصب کنید. به عنوان مثال libpng ، zlib . برای توضیحات بیشتر به سایتهای زیر مراجعه کنید :

libpng
zlib

3- در انتها php را با پارامتر زیر پیکر بندی کنید :

--with-gd[=DIR]

( DIR محل نصب gd است.)
تمام این موارد تنها زمانی مورد استفاده قرار می گیرد که php از روی source نصب شده باشد. در صورتی که از RPM استفاده شده باشد ، می توان از php-gd استفاده کرد. این RPM پیش نیازهای مربوط به GD و خود آن را نصب کرده و تغییرات مورد نیاز را نیز اعمال می کند.
4- در انتها مجددا ()phpinfo را کنترل کنید تا از نصب GD اطمینان حاصل کنید .

مشکل با MailEnable

شیما دهباشی — Sun, 23 Jul 2006 10:07:00 GMT

گاهی این مساله پیش می آید که به هر دلیل quee مربوط به SMTP در Mailenable مملو از ایمیل شود. به عنوان مثال برنامه ای به اشتباه در حال ارسال بیش از 20000 ایمیل به یک mailbox خاص باشد ! در این مرحله تنها outbound شما سرشار از ایمیل خواهد شد. مشکل زمانی بدتر می شود که mailbox مربوط به گیرنده اصطلاحا Over quota شود و mail server مقابل نیز به ازای هر ایمیل برای شما پیام خطا ارسال کند. اگر در هر ثانیه 5 ایمیل ارسال کنید می توانید تصور کنید پس از 10 دقیقه 3000 ایمیل به شما ارسال می شود و این قضیه همینطور ادامه پیدا می کند. در این زمان ممکن است ایمیل ارسال کننده را غیر فعال کنید که وضعیت بدتر هم می شود چون تمامی ایمیلها باید برگشت بخورند و مجددا outbound نیز هر لحظه منتظر ارسال ایمیل جدیدی خواهد بود. - البته در این زمان میل سرور به هیچ عنوان نه میلی ارسال خواهد کرد و نه ایمیلهای دریافتی را به مقصد می رساند.در این زمان به خوبی می بینید که پروسس های مربوط به Mailenable تمام حافظه را گرفته اند .به نظر می رسد که restart کردن ایمیل سرور و حتی سرور تاثیری در قضیه داشته باشد اما عملا سودی به حال شما ندارد - ایمیلی که ارسال نشده همواره در queue وجود دارد و پس از چند دقیقه دوباره عمیلیات ارسال و دریافت ایمیلهای ناخواسته ادامه می یابد.بنابراین ما به صورت زیر عمل کردیم :

اگر فکر میکنید برنامه هنوز در حال ارسال ایمیل است بهتر است سایت را غیر فعال کنید . برای اطمینان از اینکه روند ارسال و دریافت ادامه دارد نگاهی به activity log بیندازید تا اطمینان حاصل کنید که کسی غیر از account مورد نظر شما در حال ارسال ایمیل نباشد . برای مطالعه دقیق تر activity log می توانید از این صفحه استفاده کنید :

http://www.mailenable.com/kb/Content/Article.asp?ID=me020170

مطمئنا با توجه به اینکه تمامی ایمیل های شما با تاخیر ارسال می شوند برای ارسال آنها یک delay notifier نیز ارسال می گردد ، پس در قسمت delivery مربوط به SMTP ، ارسال Delay notifier را غیر فعال کنید. شاید اگر mail server در حال ارسال ایمیل باشد ، بد نیست که برای خالی کردن quee تعداد تلاشهای مربوط به ارسال ایمیل را به کمترین زمان ممکن کاهش دهید تا پس از نهایتا یک بار عدم توفیق در ارسال هر ایمیل ، ایمیل مورد نظر از queue حذف شود. برای این کار در بخش delivery در SMTP امکانات لازم جهت اینکار وجود دارد.البته در نظر داشته باشید دو مساله در این جا مطرح می شود :
1- ممکن است ایمیلهای واقعی نیز از queue حذف شوند.
2- در حالتی که میل سرور شما توانایی مدیریت ایمیل ها را برای ارسال و دریافت ایمیل ندارد ، این کار فایده چندانی ندارد!

ما سعی کردیم، تا دامنه مربوط به remote mail server را در blacklist قرار دهیم اما متاسفانه تاثیری در وضعیت دریافت ایمیل ها ایجاد نکرد. -چون ایمیلهایی د در queue موجود بود -به هر صورت مجبور شدیم میل سرور را متوقف کنیم !

مساله مهمتر این بود که ما در حدود 16000 ایمیل نادرست در outbound داشتیم در حالیکه به علت تعداد زیاد ایمل حتی نمی توانستیم مستقیما آنها را درqueue ببینیم .در inbound هم وضعیت بهتری برقرار نبود زیرا که 6000 ایمیل موجود نه تنها قابل دیدن نبودند ، بلکه مستقیما قابل حذف هم نبودند. البته استفاده از محل فیزیکی نگهداری ایمیلها نیز کمک چندانی به شما نمی کند. چون در هر حال شما نمی توانید روی فایلهای موجود جستجوی بر مبنای محتوا انجام دهید تا ایمیلهای مورد نظر خود را حذف کنید.
اما خوب پس از اینکه ما مطمئن شدیم دیگر ایمیل جدیدی به quee ها وارد نمی شود و هرچه که هست ناشی از ارسال همان ایمیلهای موجود است ، با استفاده از برنامه زیر queue های را با بکاربردن ایمیل مورد نظر به عنوان کلیدواژه - که طبیعتا در تمام ایمیل ها بود - حذف کردیم :

http://www.mailenable.com/kb/Content/Article.asp?ID=me020250

در انتها به راحتی می توانید میل سرور را start کنید و پس از دقایقی میل سرورو سرور شما به حالت پایدار بر می گردند.