Αγαπητοί συνάδελφοι της κοινότητας.

Είναι αυτονόητη η παρουσία μου στην εκδήλωσή μας.

Dr Iordanis Tsafaridis

BSc, MSc, MBa, PHD

Αγαπητοί συνάδελφοι,

Ευτυχισμένο το νέο έτος.

Εύχομαι να παραμείνουμε αθεράπευτα αισιόδοξοι και να επιμένουμε να αναζητούμε την αχτίδα φωτός μέσα στο σκοτάδι.

Δρ Ιορδάνης Τσαφαρίδης

Επιτέλους η είδηση για τους IT Pros της χρονιάς που τρέχει.

 

Και όπως λέει και ο αξεπέραστος Θανάσης Βέγγος ως Πράκτωρ Θου-Βου Βουρ για IT Pro| Dev Connections 2010!!!!!!!!

 

Δρ Ιορδάνης Τσαφαρίδης

ΙΤ Manager

BTI Hellas AEE

 

Αγαπητοί συνάδελφοι της κοινότητας καλησπέρα και σας εύχομαι Καλή Ανάσταση σε όλους σας και στις οικογένειές σας.

 

Λαμβάνοντας αφορμή από την πρόσφατη δημοσίευση με τίτλο "Second MX record for exchange", παρακάτω παραθέτω το παρακάτω άρθρο αυτούσιο στην Αγγλική.

 

Δυστυχώς δεν είχα τον απαραίτητο χρόνο για να το μεταφράσω. Ελπίζω ότι ο xrisxal2000 θα βρει τις απαντήσεις τις οποίες χρειάζεται στο θέμα του στο άρθρο αυτό.

 

Ιορδάνης Τσαφαρίδης

 

Configure MX Records for Incoming SMTP E-Mail Traffic

How do I configure and test the MX Record for my Internet Domain name?

When you want to run your own mail server, and it does not matter

what version and make of mail server you're using - as long as the mail

server is using SMTP as the e-mail transfer mechanism - you'll need to

configure the MX Records for your domain.

MX is an acronym for Mail eXchange. MX is defined in RFC 1035. It specifies

the name and relative preference of mail servers for the zone. MX is a

DNS record used to define the host(s) willing to accept mail for a given

domain. I.e. an MX record indicates which computer is responsible for

handling the mail for a particular domain.

Without proper MX Records for your domain, only internal e-mail will

be delivered to your users. External e-mail from other mail servers in

the world will not be able to reach your server simply because these

foreign servers cannot tell to which server they need to "talk" (or open

a connection to) in order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in

preference order. If a host has three MX records, a mailer will try to

deliver to all three before queuing the mail.

MX Records must be in the following format:

domain.com.    IN    MX   10     mail.domain.com.

The Preference field is relative to any other MX Record for the zone

and can be on any value between 0 and 65535. Low values are more

preferred. The preferred value is usually 10 but this is just a

convention, not a thumb rule. Any number of MX Records may be defined.

If the host is in the domain it requires an A Record. MX Records do not

need to point to a host in the same zone, i.e. an MX Record can. point

to an A Record that is listed in any zone on that DNS or any other DNS

server.

External and Internet-connected networks

When connecting your mail server to the Internet (or to another

ex-organizational mailing system that uses SMTP) you must always make

sure that the rest of the world can successfully resolve your domain's

MX Record. Failing to do so will cause e-mail traffic not to be

delivered to you.

In order to properly configure your domain's MX Record you should

contact your ISP (Internet Service Provider) or the party responsible

for hosting your DNS Domain name. They will ask you for your FQDN (Fully

Qualified Domain Name) and IP address of your mail server. Make sure

you know them.

When your mail server is connected directly

to the Internet

In cases where no NAT (Network Address Translation) is being used and

where your mail server is directly connected to the Internet, you will

need to provide them with the FQDN and IP address of your mail server.

Note: This is, by far, the least secure method for

connecting a mail server to the Internet.

Let's say you have the following LAN configuration:

In the above example you need to give the mail server's IP address as

your MX Record.

Domain name: dpetri.net

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	212.143.143.130
dpetri.net	MX	mail.dpetri.net	10

You should make sure the ISP has had all the necessary routing tables

updated in order to provide Internet availability to your internal IP

network range.

Note: It doesn't matter if the real host name of the

mail server is NOT "mail". Internet hosts don't mind that, they just

need to know what's the name of the mail server, and what's the IP

address for that name.

When NAT is being used

In cases where NAT (Network Address Translation) is being used you

will need to provide them with the IP address of your external NAT

interface, and configure your NAT device with Static Mapping for TCP

Port 25, and have all TCP Port 25 traffic forwarded to the internal IP

address of your mail server.

Let's say you have the following LAN configuration:

In the above example you need to give the NAT's IP address as your MX

Record.

Domain name: dpetri.net

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	192.90.1.1
dpetri.net	MX	mail.dpetri.net	10

Note: Make sure you properly configure the NAT

device to forward all TCP Port 25 traffic to 192.168.0.10.

When a Mail Relay is being used

In cases where you have a DMZ (Demilitarized Zone) with a Mail Relay

host (i.e. Linux, Windows 2000/2003 + IIS and SMTP, a dedicated

appliance and so on) you will need to provide the FQDN and IP address of

your Mail Relay machine, and configure the Firewall to only allow TCP

Port 25 traffic to be sent to the Mail Relay's IP address, not to your

real mail server.

You should then configure the Mail Relay to forward the incoming

e-mail traffic to the real mail server (after scanning it for spam,

viruses and so on).

Let's say you have the following LAN configuration:

 

 

In the above example you need to give the Mail

Relay's IP address as your MX Record.

Domain name: dpetri.net

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	192.90.1.17
dpetri.net	MX	mail.dpetri.net	10

Note: Make sure you properly configure the Firewall

device to forward all TCP Port 25 traffic to 192.90.1.17, and to allow

192.90.1.17 to send TCP Port 25 traffic to your internal mail server at

192.168.0.10. Also, make sure you let the internal mail server

communicate only with the Mail Relay device and that you set up an SMTP

Connector on the mail server and configure it to relay all external mail

to the Mail Relay.

Note: Some networks might use the Internet Router as

their NAT device, and let the Firewall do just that. In those cases,

the scenario is a mixture between option #2 (NAT) and this one.

Internal networks

As stated above, there is usually no need to configure MX Records for

internal use, simply because internal (i.e. inter-organization) e-mail

and replication traffic is usually controlled via Active Directory-store

information. However there are some cases where you will want to

configure internal MX Records.

While these MX Records will generally not cause any harm even if you

configure them without actually needing them, you must pay close

attention to various configuration issues, especially when Mail-Relays

and Smart-Hosts are involved. Therefore I cannot say for sure if

configuring non-necessary MX Records will cause any problems to your

local network. If you do not know for sure (and this might be the case

since you've bothered to read this article in the first place) I suggest

you consult a network specialist before doing any changes.

Fault Tolerance

In case your mail server fails you'd like to still be able to receive

incoming e-mail messages. Most small to medium sized companies will pay

their ISPs some monthly fee and that will buy them storage space on the

ISPs mail servers. For that to happen, a new MX Record will be added to

their DNS information, pointing to the ISPs mail server with a higher

priority. For example:

Record FQDN	Record Type	Record Value	MX Pref
mail.dpetri.net	A	192.90.1.17
mail.isp.com	A	212.143.25.1
dpetri.net	MX	mail.dpetri.net	10
dpetri.net	MX	mail.isp.com	100

Load Balancing

Medium to large sized companies will want to configure some load

balancing features for their incoming mail servers. For that to happen,

the company must set up a number of mail servers, each one with a

different IP address (actually, one can use Network Load Balancing -

NLB, or even clustering but that's a topic for a different article).

Then new MX Records will be added to their DNS information, pointing to

the mail servers, all with the same priority. For example:

Record FQDN	Record Type	Record Value	MX Pref
maila.dpetri.net	A	192.90.1.17
mailb.dpetri.net	A	192.90.1.18
mailc.dpetri.net	A	192.90.1.19
mail.isp.com	A	212.143.25.1
dpetri.net	MX	maila.dpetri.net	10
dpetri.net	MX	mailb.dpetri.net	10
dpetri.net	MX	mailc.dpetri.net	10
dpetri.net	MX	mail.isp.com	100

Testing the MX Record configuration

Testing the MX Record configuration is critical especially when

configuring it for the first time with a new ISP you don't know that

well and so on. Use NSLOOKUP or DIG or any other DNS querying tool to

make sure your records are set straight.

Sample screenshot is of an NSLOOKUP test to Microsoft's MX Records:

Also, make sure you can connect to the mail server by using the MX

Record information. You can do so by using Telnet, as described in the SMTP, POP3 and

Telnet in Exchange 2000/2003 and Test SMTP Service in

IIS and Exchange articles.

 

 

 

Με τον όρο Relaying αναφερόμαστε στην μεταφορά μηνυμάτων ηλεκτρονικού ταχυδρομείου

από ένα server σε έναν άλλο. Είναι απαίτηση να μην επιτρέπεται σε μη

εξουσιοδοτημένους αποστολείς (unauthorized senders)

– με άλλα λόγια spammers – να χρησιμοποιούν τον Exchange Server σας ως SMTP relay έτσι

ώστε να κρύβουν την πραγματική διεύθυνση των μηνυμάτων τα οποία στελνουν.

 

Με το κείμενο

αυτό θέλω παρουσιάσω μια μεθοδολογία βάση της οποίας μπορούμε να διαπιστώσουμε εάν

ο mail server μας κάνει ή όχι relaying. H διαδικασία είναι πολύ απλή και το μόνο το οποίο απαιτείται

είναι ένας ηλεκτρονικός υπολογιστής ο οποίος βρίσκεται εκτός του δικτύου της εταιρίας

στην οποία εργάζεται ο καθένας μας. Όλες οι εντολές οι οποίες απαιτούνται

παρουσιάζονται στους παρακάτω πίνακες και εκτελούνται από command prompt.

 

Στα παρακάτω

παραδείγματα, όπου mail.example.com είναι ο mail server για τον οποίον

θέλετε να διαπιστώσετε εάν κάνει relaying ή όχι. Αντιστοίχως sender@example.gr είναι ένας έγκυρος λογαριασμός

ηλεκτρονικού ταχυδρομείου στον συγκεκριμένο email server - στο παράδειγμά

μας mail.example.gr (μπορεί να είναι και μια fake email address) - , και τέλος youremail@outsideaddress.gr είναι ο λογαριασμός ηλεκτρονικού ταχυδρομείου στον οποίο

θέλετε να στείλετε το συγκεκριμένο μήνυμα.

 

Οι εντολές τις οποίες

πρέπει να πληκτρολογήσετε είναι αυτές οι οποίες βρίσκονται στην αριστερή στήλη του

κάθε πίνακα και οι απαντήσεις τις οποίες θα πρέπει να λάβετε βρίσκονται στην

δεξιά στήλη του κάθε πίνακα.

 

Το παρακάτω παράδειγμα

παρουσιάζει έναν mail server ο οποίος ΔΕΝ

ΕΠΙΤΡΕΠΕΙ relaying.

 

Πληκτρολογείτε το παρακάτω κείμενο	Ο Server πρέπει να απαντήσει
TELNET mail.example.gr 25	Trying 10.10.10.1. Connected to mail.example.gr. Escape character is '^]'. 220 mail.example.gr
HELO mail.example	250 OK
MAIL FROM:<[email protected]>	250 OK - Mail from <[email protected]>
RCPT TO:<[email protected]>	550 Relaying is prohibited
QUIT	221 Closing connect, good bye

 

Το παρακάτω παράδειγμα

παρουσιάζει έναν mail server ο οποίος ΕΠΙΤΡΕΠΕΙ

relaying.

 

Πληκτρολογείτε το παρακάτω κείμενο	Ο Server πρέπει να απαντήσει
TELNET mail.example.gr 25	Trying 10.10.10.1. Connected to mail.example.gr. Escape character is '^]'. 220 mail.example.gr
HELO mail.example	250 OK
MAIL FROM:<[email protected]>	250 OK - Mail from <[email protected]>
RCPT TO:<[email protected]>	250 OK
DATA	354 End data with <CR><LF><CR><LF>
From: [email protected] To: [email protected] Subject: Relay test This is a relay test and only a test. (type  <CR><LF>.<CR><LF> or [enter].[enter] to end data)	250 OK: Queued as T22122A5
QUIT	221 Closing connect, good bye

 

Οδηγίες για τις ρυθμίσεις οι οποίες απαιτούνται έτσι ώστε ο MS -  Exchange 2003 να μην λειτουργεί ως open relay θα βρείτε σε αυτόν τον σύνδεσμο :

 

 

http://www.petri.co.il/preventing_exchange_2000_2003_from_relaying.htm

 

 

1. Open exchange 2007 console and

   go to "Organization Configuration" and then to "Hub

   Transport"

2. Select

   "Transport Rules" tab

3. From the

   "Action Pane" on the right select "New Transport Rule"

4. Type any

   name and any comment and press next

5. From the

   conditions window select "From users inside or outside my

   organization" and "Send to users inside or outside my

   organization" and from the details select the "Inside"

   links and switch both to "outside" then press next

6. From the

   "Actions" window select the last action "Silently drop the

   message" and press next

7. If you

   have any exceptions you can configure it in the "Exceptions"

   window ,If not just press next again

8. Press

   "New" then "finish"

 

 

 

Τα παραπάνω απαγορεύουν οποιοδήποτε email το οποίο έχει αποσταλεί από τον οποιοδήποτε

εκτός της εταιρίας στην οποία εργάζεστε και παραλήπτης είναι πάλι κάποιος ο οποίος

είναι εκτός της εταιρίας, δηλαδή δεν επιτρέπει στον Microsoft Exchange

Server 2003/2007 να γίνει relay server.

 

Αγαπητοί συνάδελφοι την κοινότητας ελπίζω να

το βρείτε χρήσιμο.

 

Ιορδάνης

Τσαφαρίδης

Θανάση βεβαίως και το έχω δοκιμάσει.

 

Μάλιστα βρίσκεται σε λειτουργία από τον περασμένο Οκτώβριο χωρίς προβλήματα.

 

Ιορδάνης

 

 

Αγαπητοί συνάδελφοι του autoexec.gr παρακάτω σας παραθέτω την Εφαρμογή αλγορίθμου ασφαλείας Captcha Validation σε περιβάλλον OWA 2007 με Forms-Based Authentication.

Δεδομένης της αυξανόμενης ζήτησης για ασφάλεια σε κάθε μορφή διαδικτυακής επικοινωνίας πιστεύω ότι το παρακάτω άρθρο είναι πολύ χρήσιμο για όποιον θέλει πραγματικά να ασφαλίσει με ένα επιπλέον επίπεδο ασφαλείας το logon page του outlook web access 2007.

 

Δυστυχώς λόγω ελλείψεως χρόνου δεν προλαβαίνω να μεταφράσω το κείμενο από τα αγγλικά στα Ελληνικά, αλλά το κείμενο είναι απόλυτα κατανοητό :

 

 

CAPTCHA

stands for Completely Automated Public Turing test

to tell Computers and Humans Apart. You will no doubt have

seen this implemented in various web pages as an image of a visually distorted

common word, which must be typed into an input field, thus proving that you are

indeed a real person. This has become necessary to prevent the actions of bots,

which roam the web looking for opportunities to inject spam into message boards,

etc. Shown here in Figure 1 is an example of such an image. The idea is

that a human user will recognize the word 'part', whereas a spambot will not.

 

 

Figure

1:  A CAPTCHA image displaying

the word 'part'

 

OWA Forms-based Authentication is very secure by

itself, of course, since you still need to supply valid credentials to log in,

but there is still a significant amount of interest in adding CAPTCHA

validation to it. Here, I will show how it can be done by modifying

Exchange's logon.aspx file. I have chosen to use a freely available

CAPTCHA script written by Jonathan Feaster, which is available for download

from Archreality (http://www.archreality.com/jcap/) . This script uses JavaScript, and unlike some other

solutions has the advantage of not requiring a second .aspx page to process the

form input; the validation is done by the user's browser before the credentials

are sent to the OWA server. Any CAPTCHA scripts which require a second

page will not work with FBA, since there is no opportunity to insert anything

between the logon page and the OWA GUI.

 

Procedure

 

First, extract the files to a suitable place on the

server. There are two .js files, and a folder named cimg, which

contains the word images to be displayed on the logon page. Place the

entire extracted jcap folder in the C:\Program

Files\Microsoft\Exchange Server\ClientAccess\Owa\auth folder as shown in

figure 2:

 

 

Figure

2: The extracted jcap files in

the auth folder

 

Next, use Explorer to locate the logon.aspx file that

creates the FBA logon page. This is inside the same auth folder

that you just placed the jcap folder into. Before doing anything else,

make a backup copy of the logon.aspx file. Right-click it, then select

Copy, then right-click the folder, and then select Paste. This creates a

copy of your logon.aspx file named 'Copy of logon.aspx' . If your

modifications are unsuccessful, you will need to revert to this original file

to restore FBA functionality.  Now, open the logon.aspx using

Notepad. I'm going to insert the image just above the 'Public Computer'

radio button, so press F3 and search for the text rdoPblc

. Assuming that you successfully found the text, insert the following just

before the preceding <tr> tag:

 

<script

type="text/javascript" language="javascript"

src="jcap/md5.js"></script>

 

<script

type="text/javascript" language="javascript"

src="jcap/jcap.js"></script>

 

<script

type="text/javascript" language="javascript">                                                                                                               

function doJcap()

 

{

 

if (jcap() ==

true)

 

{document.forms[0].action

= "owaauth.dll"; return true;}

 

else

 

return false

 

}

 

</script>

 

<tr><td

colspan="2" align="center">

 

Enter the code as it is shown below

 

<script

language="JavaScript">sjcap();</script>

 

<noscript>This

resource requires a JavaScript enabled browser</noscript>

 

</td></tr>

 

The result should look something like figure 3:

 

 

Figure

3: The amended contents of

logon.aspx in Notepad

 

Next, press CTRL-HOME to go back to the top of the

file, and then press CTRL-F, and search for the text <form (without a

closing angled bracket). Assuming that you successfully found the form

tag, remove its action attribute and replace it with the following text:

 

onsubmit="return

doJcap();"

 

This part of the page should now look like that shown

in figure 4:

 

                                                

Figure 4: The modified <form> tag

 

Now save the file back to disk, and close

Notepad. All that is required now is a small change to the jcap.js

file that was saved in C:\Program Files\Microsoft\Exchange

Server\ClientAccess\Owa\auth\jcap . Right-click the jcap.js file, and

select Edit.  It should open in Notepad. On the line that begins with

var imgdir, you need to change the path to point to the current location

of the cimg folder. Change it so that the beginning of the line looks like

this:

 

var imgdir =

"/owa/auth/jcap/cimg/";

 

The complete line looks like this:

 

 

Figure

5:  Defining the path to the

image files

 

Save the file, and we're finished. The next time

you open the FBA logon page, it should look something like this (figure

6). Also shown is the alert message displayed if the typed text does not

match the distorted text in the image when you click the Log On button.

 

 

Figure

6: The modified FBA logon page

 

Please remember that due to updates made by Exchange

service packs and patches, future versions of the logon.aspx file may be

different to the version shown. The basic principles described should, however, remain the

same.

 

References

 

• CAPTCHA

  described at Wikipedia

• Turing

  test discussed at Wikipedia

• The CAPTCHA Project

 

·        

A CAPTCHA or Captcha

(pronounced /ˈkæptʃə/) is a type of challenge-response test used in computing to

ensure that the response is not generated by a computer. The process usually

involves one computer (a server) asking a user to complete a simple test which the

computer is able to generate and grade. Because other computers are unable to

solve the CAPTCHA, any user entering a correct solution is presumed to be

human. Thus, it is sometimes described as a reverse Turing test, because it is administered by a machine and targeted

to a human, in contrast to the standard Turing test that is typically administered by a human and

targeted to a machine. A common type of CAPTCHA requires that the user type

letters or digits from a distorted image that appears on the screen.

 

·        

The term "CAPTCHA" (based

upon the word capture) was coined in 2000 by Luis von Ahn, Manuel Blum, Nicholas J. Hopper (all of Carnegie Mellon University), and John

Langford (then of IBM). It is a contrived acronym for "Completely Automated Public

Turing test to tell Computers and Humans Apart."

Carnegie Mellon University attempted to trademark the term,^[2]

but the trademark application was abandoned on 21 April 2008.^[3]

Currently, CAPTCHA creators recommend use of reCAPTCHA as

the official implementation.^[4]

Ελπίζω να το βρείτε χρήσιμο.

Ιορδάνης Τσαφαρίδης

 

 

 

Αγαπητοί συνάδελφοι του Autoexec.gr ως μέλος της κοινότητας θα ήθελα να δηλώσω ότι θα είναι χαρά μου να παραβρεθώ στην εκδήλωση αυτή.

 

Ιορδάνης Τσαφαρίδης

 

http://blogs.technet.com/isablog/archive/2009/11/17/forefront-threat-management-gateway-2010-release.aspx

Τα νέα χαρακτηριστικά url filtering και anti-malware είναι κορυφαία.

Μια μέρα μετά την ανακοίνωση του TMG 2010 , η Gfi ανακοίνωσε την ανεξαρτοποίηση του gfi web monitor 2009 απο τον ISA Server.Βλέπετε τώρα ο αντικαταστάτης του ISA , ο TMG 2010 υποστηρίζει  url filtering και anti-malware protection.Ακόμη Θα περιμένουν λίγο ακόμη οι συνδρομητές msdn-technet για να γίνει διαθέσιμο.

Μειονεκτήματα (άποψη μου)  ούτε σε αυτήν την έκδοση δεν υποστηρίζεται το traffic shaping για όσους το θέλουν.Ενναλακτικά στον ISA υπάρχει το Bandwidth Splitter. Ακόμη με την άφιξη του νέου vpn πρωτοκόλλου SSTP , θα ήθελα να υπάρχει και sstp client για windows xp και όχι μόνο(κάτι σαν open sstp client) ενώ υποστηρίζεται μόνο απο Vista και Win7.

Αξίζει να το δοκιμάσετε.

 

 Έχοντας ως αφαιτηρία την κυκλοφορία της τελικής - εμπορικής έκδοσης του Microsoft ForeFront TMG 2010, και έχοντας ήδη το λογισμικό αυτό σε παραγωγική λειτουργία στο δίκτυο της εταιρίας στην οποία εργάζομαι, έχω να πω ένα μεγάλο μπράβο στην microsoft η οποία όχι μόνο βελτίωσε το λογσιμικό σε σχέση με τον ISA SERVER 2004/2006, αλλά στην ουσία παρουσίασε ένα προϊόν το οποίο στέκεται αντάξια έναντι των απαιτήσεων των χρηστών της συγκεκριμένης κατηγορίας προϊόντων.

θα ήθελα και εγώ με την σειρά μου έστω κα καθυστερημένα να απαυθύνω ένα μπράβο στον Σωτήρη για τα video. Επιπλέον θα ήθελα να ενημερώσω την κοινότητα ότι η microsoft για τον TMG 2010 επέλεξε για μένα προσωπικά αλλά και σύμφωνα με τον διεθνή εκειδικευμένο τύπο την καλύτερη βιβλιοθήκη URL Filtering η οποία είναι αυτή της M86Security πρώην Marshal (MailMarshal, WebMarshal, MailMarshal SMTP), η οποία συναγωνίζεται στα ίσια εκείνη της Symantec.

 

 

 

 

Πρόσφατα λόγω κάποιας δυσλειτουργίας στην εγκατάσταση του Microsoft Exchange Server 2007 SP2, αναγκάστηκα να επαναφέρω τον Exchange Server 2007 μέσω του λογισμικού Symantec BackUp Exec for Windows Servers με επιτυχία. Εν συνεχεία εγκατέστησα εκ νέου με επιτυχία το Microsoft Exchange Server 2007 SP2.

 

Το πρόβλημα το οποίο υπάρχει είναι ότι ενώ το Microsoft Outlook 2007, αποστέλει μηνύματα ηλεκτρονικού ταχυδρομείου, δεν λαμβάνει μηνύματα. Εάν συνδεθώ μέσω του Microsoft Outlook Web Access τα νέα μηνύματα λαμβάνονται κανονικά και τα βλέπω. Μετά από έρευνα στο διαδίκτυο το πρόβλημα εντοπίζεται στο ότι υπάρχει Outlook Cache Synchronization after Exchange 2007 restore.

 

Εάν κάποιος από τους αγαπητούς συναδέλφους του autoexec.gr έχει αντιμετωπίσει με επιτυχία αυτό το πρόβλημα θα παρακαλούσα πάρα πολύ να έχω την μεθοδολογία επίλυσής του.

 

Ευχαριστώ πολύ εκ των προτέρων για την βοήθειά σας.

 

Δρ Ιορδάνης Τσαφαρίδης

BTI Hellas AEE

 

Σε ευχαριστώ πολύ πρώτα απ' όλα για την άμεση ανταπόκριση.

 

Τα δύο πρώτα σημεία τα οποία αναφέρεις τα έχω ήδη περάσει από λεπτομερή έλεγχο.

 

Τώρα όσον αφορά το τρίτο, να κάνω telnet τον exchange server από τον gfi faxmaker server και το αντίστροφο?

 

Βέβαια θα ήθελα να ενημερώσω την παρέα του autoexec ότι ψάχνοντας στο διαδίκτυο το πρόβλημα απ'ότι φαίνεται είναι γνωστό σε πολύ κόσμο και το γνωρίζει και η ίδια η microsoft.

 

Ευχαριστώ πολυ για μια ακόμη φορά.

 

Ιορδάνης Τσαφαρίδης

 

Αγαπητοί φίλοι του autoexec.gr, θα παρακαλούσα να έχω την βοήθειά σας στο παρακάτω πρόβλημα το οποίο αντιμετωπίζω :

Στην εταιρία στην οποία εργάζομαι έχω εγκατεστημένο τον Microsoft Exchange Server 2007 SP1, σε λειτουργικό περιβάλλον windows Server 2008 active directory. Το σύστημα λειτουργεί άψογα εκτός από την συνεργασία του με το GFI Faxmaker Server for Exchange SMTP λογισμικό το οποίο τρέχει σε ξαχωριστό server.

Για να είναι δυνατή η λήψη και η αποστολή fax μέσω απαιτείται η δημιουργία στον Exchange server ενός Receive και ενός Send Connector.

O Receive Connector είναι απαραίτητος για την λήψη των εισερχομένων fax, ενώ ο δε Send Connector για την αποστολή των εξερχομένων fax.

Ο Receive Connector λειτουργεί άψογα σε αντίθεση με τον Send Connector ο οποίος δεν λειτουργεί και παρουσιάζει το παρακάτω μήνυμα λάθους στην κονσόλα του Exchange server/Toolbox/queue viewer:

451 4.4.0 Primary Terget IP address responded with error : 421 4.2.1 Unable to Connect.

Αυτό έχει ως αποτέλεσμα να μην είναι η δυνατή η αποστολή μηνυμάτων fax της μορφής τηλ_αριθμός@faxmaker.com ([email protected]) μέσω του microsoft outlook 2007.

Κάθε πρόταση για βοήθεια δεκτή.

Δρ Ιορδάνης Τσαφαρίδης

Υπεύθυνος Μηχανογράφησης

BTI Hellas A.E.E.