Hi nick37-ga,
This question is not one that I feel can be answered completely
without some back and forth on clarifications (as you've indicated).
So, please DO NOT RATE this answer until you are satisfied with the
results.
I was able to locate a step-by-step guide to installing SMTP on your
Windows 2000 machine. The page is, "howTo Confiure a Windows 2000 SMTP
Server" and it is found here:
http://www.skybuilders.com/users/jesse/docs/howToSMTP.html
Once you have completed the install as listed on that site, (with
making the appropriate changes where needed), you'll also need to
configure your Outlook client to use the new SMTP server. You'll need
to change the SMTP info to your own hostname and the new SMTP port at
2525 (as per the directions on the above site).
The changes from the above site that you will need to make is:
* enter your OWN hostname and domain name instead of the "skyspec"
info.
* enter your OWN IP address into the Relay from info (or whatever is
appropriate if your IP changes frequently: probably the domain name
would be the most appropriate to allow relaying from)
* When it recommends to use a drive letter of "G:\", ignore it for a
directory on C:\. However, use a different directory than the default.
SO, use C:\SMTPMail where the instructions suggest
g:\inetpub\...etc...
There are other SMTP servers available for Windows that may be easier
to use/install. For example, Pegasus Mail has a MTA that is free to
use and download. You can find more about Pegasus Mail's MTA at the
Pegasus Mail homepage located here:
http://www.pmail.com/
If you decide that Pegasus is the way you prefer, I'll give you a
step-by-step on that product. I had Pegasus SMTP up and running in
about 2 minutes--with no prior knowledge of the software whatsoever!
I will work with you on getting your SMTP server up and running on
Windows--so, please DO NOT RATE this answer until you are satisfied
with the results.
Thanks!
Legolas-ga
Search used:
smtp server windows |
Request for Answer Clarification by
nick37-ga
on
26 Dec 2002 07:32 PST
Legolas,
First off - cool alias.
I appreciate your reply. I've looked into both of your suggestions
and hope one of them will work. Here are some thoughts/questions on
each:
1) Skybuilders SMTP instructions
* I also ran across this in my earlier research. I had disregarded
because of the focus on "skyBuilders timeLines" (I just want to send
some emails!), but took a closer look at your suggestion.
* The setup instructions do not work precisely for me. I am unable
to create a new SMTP Virtual Server. For example: "Highlight the
computer enummerated in the IIS display, skyspec3 in the illustration,
and right click the entry. Selecting New > SMTP Virtual Server." This
right click on the computer does not bring up an option for "New".
This may be because I access through the MMC (just typing MMC from the
Run command line and adding the IIS snap in). Alternatively, I can
see the Virtual SMTP server from Start>Settings>Control
Panel>Administrative Tools>Computer Management>Services &
Applications>Internet Information Services, but this view does not
show the computer at all, just the Default FTP, Web Site, and SMTP
Virtual Server.
2) Pegasus
I'm open to a 3rd party software for SMTP that comes well recommended.
I'm assuming that this is a program that would send email from my PC
rather than act as a "yahoo-style" intermediary. Between the
website's quals and your experience, I'm open to Pegasus if you would
recommend.
This is where I go from standing on my tip toes in the pool to dog
paddling. As you know, I'm just wanting to send emails without the
endless Exchange syncs through my company or the yahoo stamp on my
email.
If you recommend one of the two options above as the best solution,
then let me know next steps and we can give it a try.
|
Request for Answer Clarification by
nick37-ga
on
26 Dec 2002 08:17 PST
In response to Joseleon:
I'm wanting to receive via my company's pop3 via any internet
connection (I can do that now).
I also want to send from any internet connection without going through
my company's endless Exchange syncs or having yahoo's address stamped
on all of my email. (I've been told that Windows 2000 Professional
can do this).
When you ask how, I would do it, I really don't know more specifically
than what I described above. That really is my question.
With regard to web mail, I do have web mail access. I log in through
Exchange Server via any internet access. I can view my email through
Microsoft Outlook Web Access.
However, I'm wanting my only point of contact with email to be Outlook
2000. When I am offline (say on the plane). I need to be able to
view and reply to any and all emails, so they must be resident on my
pc rather than a server. Emails queue up in my outbox and send next
time I log onto the internet.
|
Clarification of Answer by
legolas-ga
on
26 Dec 2002 09:39 PST
Ok, let's use the Pegasus Solution seeing as you're ok with 3rd party
software. Quite frankly, I'm a Microsoft Certified Professional, but I
find that Microsoft's software can be overwhelmingly complicated for
little or no valid reason: other than to make it seem more
"Professional"... Honestly I was tempted to suggest a Linux runtime
library and compile you a sendmail solution--but, that's just a tad
too complicated for Google Answers!
Anyways, onto Pegasus... SMTP is not a particularly complicated
protocol. I can actually show you how to literally send mail by hand
with a copy of TELNET and a few easy to use typed commands once
connected to the SMTP server of your choice. So, any program that can
do SMTP as a server is a pretty easy program to create--just a few
RFC's and you're done. (If that doesn't make a lot of sense to you,
don't worry.. You really don't need to know it--just makes for an
interesting interlude for those who do completely get it.)
First off, we need to grab the binary of the MTA. It's found here:
ftp://ftp.usm.maine.edu/pegasus/mercury32/m32-332.exe
Once downloaded, double click the file to start the installation
process.
The following is from: Mercury Mail Transport System, Copyright ©
1993-2002, David Harris, all rights reserved. Permission seems to be
granted to reproduce this information so long as the copyright remains
in-tact. This document is from the Help files that are installed with
the program. I will add comments where appropriate. My comments will
be preceeded by "***".
Installation overview
Installing Mercury is a fairly simple process of answering a few
questions for the setup progam, after which it will copy the necessary
files to your computer and create a basic working configuration for
you. This section of the help file aims to help you prepare for
installation by explaining what the setup program is going to ask, why
it wants to know, and how you can decide what the best answers are.
Step1: New installation, or update?
The first thing setup will ask you is whether you want to do a new
installation of Mercury, or whether it should update an existing
installation. If you choose the update option, all your existing
settings and template files will be preserved - only the actual
program files for Mercury will be upated.
If you perform an update instead of a new installation, the setup
process essentially ends at this point - Setup will simply perform the
necessary modifications and will then exit.
*** You will be doing a NEW install!
Step 2: Choosing an operating mode
If you chose a new installation at step 1, Mercury will ask you
whether or not you want to install its special support for Novell
NetWare local area networks. There are three choices at this point -
installation in NetWare Bindery mode, installation in NetWare NDS
mode, or no NetWare-specific module.
* NetWare Bindery mode is suitable for NetWare 3.x file servers and in
some cases for NetWare 4 and later versions, although we do not
normally recommend the use of Bindery mode on NDS-based servers.
* NetWare NDS mode is suitable for NetWare 4.x, 5.x and 6.x file
servers. Some extra configuration is required using the Pegasus Mail
NCONFIG utility (which is provided with Mercury/32 for this purpose).
NCONFIG is used to create user mailboxes on the file server.
* No NetWare support: this option is suitable for any environment -
you can even use it when you have a NetWare-based LAN if you want more
specific control over mailbox location and setup. You will typically
select this option if you are installing Mercury on a Windows
peer-to-peer or NT-based network, or on a single computer.
*** You will choose "No NetWare Support"
Step 3: Where to install Mercury/32
The next step simply involves telling Setup where it should actually
place the Mercury/32 program files. You can choose any directory for
this, although normally it is best to install Mercury/32 onto the hard
drive of the machine where it actually runs (as opposed to installing
it on a file server): doing this can prevent problems if your file
server crashes at any point while Mercury is running.
*** The default is fine. The program will also want to know where
Pegasus Mail is to 'integrate it' with the program. You can safely
click the 'No Pegasus Mail Integration'. Accept all the other file
locations as default.
Step 4: Selecting protocol modules and SMTP client
The next two questions involve choosing the protocol modules that
Mercury should activate by default when Mercury runs. You should read
the section of this help file entitled Installing Mercury/32 to match
your specific needs before attempting to make this choice. Note that
these questions only determine which protocol modules Mercury will
load by default - all the available protocol modules are installed as
part of the setup process, and any that you do not choose to enable at
this point in the process can be enabled at any later time using the
Protocol Modules option on the Mercury Configuration menu.
*** You will need to select ONLY the SMTP server from the list. No
other servers will be useful to you. Also, you will need to choose to
install (on the next page) the MercuryE SMTP server. It is the second
option. The other option, MercuryC is NOT what you want!
Step 5: Entering basic configuration information
Setup will now ask you for either two or three pieces of configuration
information:
This machine's internet domain name You should simply enter whatever
internet domain name has been assigned for this machine. Problems with
the Windows TCP/IP networking layer mean that Mercury cannot always
work this information out reliably by itself. Mercury uses this name
when it constructs addresses like the postmaster address for your
system, and setup will automatically create an entry in the Mercury
configuration file telling it to regard this as a "local domain" -
that is, one where Mercury is the point of final delivery.
*** This should really be the name of your computer. Bounces should
still go back to the Companies Exchange server as bounces are bounced
based on the "From" e-mail address given in the message: not by the
SMTP host.
Username for postmaster All mail-enabled Internet systems must have
a special reserved user called postmaster: rather than forcing you to
create a user called postmaster, Mercury simply treats the address as
a specialized alias for a user on your system. Enter here the name of
the user to whom postmaster mail should be directed. If you are
running in NetWare NDS or Bindery mode, then this is the full username
of the user (in NDS mode, you must express the username relative to
the root of your NDS tree in the standard dotted notation). In
non-NetWare mode, this is any valid mailbox name you subsequently
create within Mercury or in Pegasus Mail. The user need not actually
exist at setup time.
*** The default "Admin" is fine...
If you chose the MercuryC relay-based SMTP client at step 4, setup
will also ask you for the name of a host to which MercuryC should
connect when sending mail: enter the full domain name of the machine
running the SMTP server that is going to send mail on your behalf (you
can enter an IP address here as well, if you wish - this is sometimes
necessary if you are installing Mercury behind a firewall or proxy
server).
Step 6: Selecting a relaying mode
If you chose to load the MercuryS SMTP server at step 4, setup will
now ask you what default relaying protections you want to enable.
Relaying refers to the practice where a mail server accepts and
forwards mail that is not addressed to any local users on its system.
When you send a message using an SMTP-based mail client like Pegasus
Mail or Eudora, you are relaying mail. Unfortunately, relaying has
been abused in recent years by people sending unsolicited commercial
e-mail, and most sites now find it necessary to place more or less
strict controls on how their server may be used for relaying.
There are three possible answers to this question:
No relaying controls In this mode, MercuryS will act as an open
relay. We strongly advise against selecting this mode unless Mercury
is only operating on an intranet. It is considered very bad form to
have an open relay on a mail server that is actually open to the
Internet proper.
Normal relaying controls In this mode, Mercury will only relay mail
if the sender's address is a valid local address on the system other
than "postmaster". This mode prevents the majority of relaying abuse,
but requires no ongoing maintenance. We recommend this mode in most
cases.
Strict relaying controls In this mode, Mercury will only relay mail
if the sender's e-mail address is a valid local address and the IP
address of the machine from which the message is being sent has been
explicitly approved by the system administrator using a connection
control entry. This mode practically eliminates all possibility of
relaying abuse, but requires more ongoing maintenance, especially if
you have roving or remote users.
*** You will want "Normal" for the relay restriction.. It's good
enough for you use... If you find that someone is using you as a relay
(an awful small possibility quite frankly) then, you can tighten it up
even more: but, it's probably good enough at Normal.
Step 7: Choosing a mail queue location
Mercury uses a directory on your computer to store mail as it
processes it. The queue is also typically the location where local
e-mail clients like Pegasus Mail can place mail for processing by
Mercury.
If you are using Pegasus Mail, then you will typically enter a queue
directory that exists on a shared volume accessible by your Pegasus
Mail users. This will allow their copies of Pegasus Mail to submit
messages to Mercury for processing simply by placing a file in the
queue directory.
If you are not using Pegasus Mail, then it is usually best to enter a
directory on the local hard drive of the computer where Mercury is
being installed: this provides the best performance and some extra
security.
Note that if you wish, you can install the queue on the local hard
disk, then later tell Mercury to retrieve mail submitted by your
Pegasus Mail users from a secondary queue. This can offer some extra
protection from server crashes or network downtime, since Mercury will
still be able to accept incoming mail during the outage. Please
consult the main Mercury help file for more information on setting up
secondary queues.
*** Again, the default is fine..
.... And finally, it's show time.
That's it. If you've successfully navigated the setup process to this
point, all you need to do is click the Install Mercury/32 button and
Setup will do the rest. After the program is installed, run Mercury by
selecting its icon in the Windows Start menu, and explore the
program's Configuration menu for fine-tuning options. And remember,
Mercury has comprehensive online help - if in doubt, look on the Help
menu for assistance.
*** Please note, that you must actually Run the Mercury Server to
allow it to accept mail from Outlook. You can add the "Mercury
Loader" to the Startup group on the start menu to have it run
automatically. Minimizing the resultant window puts a small icon on
the task bar. Quite nice to deal with in that regard.
Now, to configure Outlook, you will need to change the SMTP info to
point to your OWN computer (localhost is a great name for that
purpose). Port 25.
And, you're done. That's seriously all there is to it. Like I said,
SMTP is not a complicated protocol.
This should get you up and running easily.
Again, if there are any parts that are unclear, please ask for
clarification and I will do my best to help you.
Thanks!
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
26 Dec 2002 12:03 PST
Legolas, here is where we are at:
* I've downloaded and installed the Pegasus MTA from the FTP site.
Install seemed to go smoothly. I also put the loader in Startup
* In Outlook 2000, I have set up a new account: "Localmail" (in
addition to the yahoo account). The account uses my company's POP3
and, for SMTP, I have put "localhost" (without parens, of course, and
the letters, not "127.0.0.1") SMTP port is set at 25.
* I rebooted for good measure, went into outlook and prepared an
email addressed to the company account. Set Localmail as the default
account. Selected send/receive for Localmail only. - email stayed in
my outbox and I received the following message:
Unable to connect to the server. (Account: 'Localmail', SMTP Server:
'localhost', Error Number 0x800ccc0e).
What do you suggest for next steps?
Best,
|
Request for Answer Clarification by
nick37-ga
on
26 Dec 2002 15:40 PST
A new issue has come up. Norton found a dozen viruses in my
c:\inetpub directory - where Windows SMTP keeps various folders. This
is despite the fact I haven't been able to get SMTP working.
By trying to work around my company's email, am I holding a big sign
to the entire internet that says "Infect me?". I can't compromise
security. Please advise.
|
Clarification of Answer by
legolas-ga
on
26 Dec 2002 17:39 PST
I'll take your two questions slightly out of order. First.. The
viruses in InetPub has nothing to do with SMTP. It's everything to do
with CodeRed (probably) and your IIS server that you installed. You've
probably not been keeping up with all the security updates, etc.. from
Windowsupdate. I need you to install ALL the updates and security
fixes that you can by going to 'Tools' then 'Windows Update' in
Internet Explorer. Then, run your virus scanner and clean your
computer. This is really a completely different question/issue, so, I
can't get too involved in the answer: but, that'll give you a good
boost.
Secondly, in Outlook. If you are receiving your e-mail from your corp.
email via. POP3, just edit the account prefs for that connection.
Change the Outgoing Mail Server to "localhost".
*** YOU WILL NEED TO REMOVE THE MICROSOFT SMTP SERVER AND ENSURE THAT
WEB SERVER, IIS, SMTP, ETC.. IS ALL REMOVED AND THE SERVICES FOR ALL
WEB RELATED MICROSOFT TOOLS ARE SET TO DISABLED! ***
Also, try this to ensure that your SMTP server is working... Open a
command prompt by going to Start, Run then run the command, "cmd".
Type, "telnet localhost 25" You should see something like "220
localhost.localdomain.com Mercury/32 v3.32 ESMTP server ready." If you
don't.. Or you see "microsoft" anywhere in the banner, again, double
check that IIS, SMTP, etc.. are ALL DISABLED AND REMOVED. That should
solve your problems. :)
Thanks again,
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
27 Dec 2002 00:21 PST
Legolas,
I've updated Windows, run the virus checker, and disabled microsoft
SMTP
SMTP appears to be working: response from the command prompt is ". .
.Mercury/32 v3.32 ESMTP server ready"
When attempting to send email in Outlook 2000, I get the following
error message: "The message could not be sent because one of the
recipients was rejected by the server. Server response: '553 We do
not relay non-local mail, sorry.' (Account: 'Localhost', STMP Server:
'localhost', Error Number: 0x800ccc79).
My company's email is set to only send email to company addresses (but
can receive from anywhere). Is this related?
|
Clarification of Answer by
legolas-ga
on
27 Dec 2002 00:43 PST
hm, I need some more clarification on that.. Typically the server will
refuse to relay non-local e-mail. That is, e-mail that came from
another computer. It's to prevent spam and spamming. If outlook is
sending the outgoing mail to mercury, mercury should be directly
sending it to the client. I somehow am thinking you installed MercuryC
instead of the necessary MercuryE server. I'd try to reinstall and
double check you selected MercuryE.. See if you still get the error...
Legolas-ga
|
Clarification of Answer by
legolas-ga
on
27 Dec 2002 00:58 PST
I've found the exact problem.. Load the Mercury SMTP server and go to
the "Configure" menu and select "MercuryS SMTP Server". Choose the
"Relay/Connection Control" tab and make sure that are no check marks
on the bottom three options. There should be no check marks anywhere
on that screen.
It should work just fine with the current settings, but, this will
loosen up the security and allow you to send the message. It is
possible that the remote computer just doesn't like your IP address
(due to spam?)... But, this will fix the problem.
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
27 Dec 2002 15:32 PST
I changed the setting (there was one option checked: "Do not permit
SMTP relaying of non-local mail" - so I unchecked it). After this
change, my emails leave the outbox fine, but take approx 1/2 hour to
arrive. I also sent a test email to a bad address that bounced back
after 1/2 hour.
1) How do I get the emails to send normally? (i.e. without delay)
2) Do my loose security settings make me a target for relaying or
virus?
|
Clarification of Answer by
legolas-ga
on
27 Dec 2002 16:52 PST
The ugly truth with SMTP is that not all hosts receive mail properly.
Or, as fast as they should, or... I had a chance to try it on my own
system--and Mercury delivered the mail immediately. However, that was
from my own computer to my own mail server (I run a Linux host that
handles my mail for me). I know from my own mail server, that some
messages take a long time to be delivered: and some messages that
bounce take a while to come back.
As for your own slow delivery, there's nothing in Mercury that I can
change to make the delivery happen "faster". If the first attempt
fails, it will wait some time before the next attempt. That's just how
SMTP servers work.
As for the looser security, it will allow relaying--but only if
someone knows where to find you. If you have a notebook where the IP
changes frequently and/or you only run Mercury when needed, quite
honestly you'll probably never have any sort of issues.
Honestly, your notebook is not going to be a particularly nice target
for spammers anyways: you're connection isn't permanent, isn't always
on, and isn't as fast as they'd want.
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
27 Dec 2002 20:40 PST
Legolas, forgive my ignorance with respect to mail serving, but I'm
still don't understand the delay and definitely need to correct to
use. I can't explain to clients and co-workers why emails I'm sending
"right now" take 30 minutes to arrive when none of them have the same
issue.
I just sent messages again to my 4 email accounts and experienced
similar delays again. None of my other accounts (current or past)
have this type of delay. Delay on the bounce-back is not a big deal
(how often do you sent to a bad email account?), but for day to day
use I need lag times of seconds or a few minutes rather than a
half-hour.
Could there be some unnecessary processing going on in the background
that can be avoided? Am I sending to a particular server (Mercury?)
that has me de-priortizied? I don't know enough about it to
understand the possible issues, just that the current set up (which is
tantilizingly close to what I need) still can't be used for business
purposes.
I definitely appreciate your help to this point and think we are very
close. What do you suggest for next steps?
Best,
|
Clarification of Answer by
legolas-ga
on
27 Dec 2002 20:57 PST
I'd like you to go into "Window", "Statistics" and "System Messages"
and post anything that *looks* like an error to you. Like I said, I've
installed the software myself, and when I send a test message from my
test installation into my production mail system, I get it within
seconds (as should be the case). It has really got to do with a
setting in your *computer* vs. Mercury, but, I'd like to make sure of
that first...
Legolas-ga
|
Clarification of Answer by
legolas-ga
on
28 Dec 2002 00:39 PST
One other thing could be the DNS resolution is a tad flaky.. SMTP is
heavily reliant on DNS information to process the mail.. Next time
you're in your office, grab the DNS server addresses from your office
and add them into Mercury as a hard-coded DNS lookup. That *might*
solve the problem... Let me know how much guidance you need to get the
DNS info and to add it to Mercury.
Thanks,
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
28 Dec 2002 07:11 PST
Nothing 'error-like' shows up under Statistics or System messages. It
seems to show the appropriate number of messages sent without any
hiccups highlighted or logged that I can tell.
With regard to the DNS server address from the office, If I describe
my logon process, maybe you can give me step by step to locate and
update.
When I'm in the office, I plug a cat5 from my notebook into a data
port and my system boots up logged onto the company system with email,
intranet, and printer access.
When I'm on the road, I can log on from any internet access, giving me
access to the company intranet.
Can I find the DNS from my remote log-on? If not, how do I identify
from the office and where to input in Mercury.
Also, with respect to my test emails. There is more variability that
I previously realized. The four accounts i sent to last night never
received the emails (what I though was another delay was actually
limbo - and no bounce-back messages). This morning I sent to the same
accounts with different results: school and personal yahoo accounts
recived right away. Business yahoo forwarded appropriately after
about 15 minutes, which probably meant it received right away as well.
The company account still has not received after about 45 minutes.
Not sure how to interpret this.
Look forward to your suggestions.
Best,
Nick37-ga
|
Clarification of Answer by
legolas-ga
on
28 Dec 2002 08:21 PST
The only possible issue could be a DNS hiccup: otherwise, it's on
"their" end, not yours.
To grab the DNS, when connected to your corporate network, go to
Start, Run, then run 'cmd'. At the C:\> prompt type, "ipconfig /all"
you will see (probably) two sets of numbers listed after DNS Servers.
Record both of those IP addresses. Then, in Mercury, go to
"Configuration" then "MercuryE SMTP client" and in the box that says,
"Name Servers" input the two IP addresses you found in step
one--separate by commas. It is POSSIBLE that your name servers are on
a private subnet, so, if this doesn't help, just simply remove the
information from the screen...
Let me know if that helps?
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
28 Dec 2002 11:34 PST
I found one IP labelled "DNS Servers", one labeled "Primary WINS
Server" and another labeled "Seconday WINS Server". I tried just the
first and then all three (separated by commas) in the MercuryE
configuration. No luck, the messages have either gone to limbo or are
substantially delayed.
|
Clarification of Answer by
legolas-ga
on
28 Dec 2002 12:17 PST
The delay must be at the recipients end then. If you are using a good
DNS server, there are no errors, etc.. then, that's as fast as you can
send a message. One of the possibilites is that the ISP you use when
away from your office does not properly do a reverse DNS lookup:
something that you can NOT fix on your end. Or, if you are attempting
to send multiple emails to sites in rapid succession, some sites do
something called, "tarpitting" where they slow your connection down as
much as possible--to prevent you from sending too many mail messages.
I believe I have done everything there is to do on my end--you are
simply seeing the REAL speed of e-mail. The only thing left is to
watch Mercury's transactions while sending a message. To do that, send
a message to a test account and see how fast Mercury shows that it has
connected to the host and sent the message.. If you see a 'waiting
for...' or similar message, let me know what it is and I can try to
trace it back for you.
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
28 Dec 2002 20:02 PST
Hmmm, I seem to be getting different messages from the various windows
within Mercury. Each email appears to be assigned a job number "e.g.
MO000001" that is reflected in the "Mercury Core Process" window.
I just sent several emails. An initial solo, then a group of four
together. They were numbered sequentially as MO000001 through 5.
A second window: "Mercury SMTP Client (end-to-end version)" reflected
" processing job MO000001, connection to ip, 3 seconds elapsed,
closing connection. This email sent right away. None of the other
emails were reflected in this window, and none of the others were
received (including later solo emails). Is getting this "processing
job . . ." message the key?
|
Clarification of Answer by
legolas-ga
on
29 Dec 2002 16:20 PST
Hi nick37,
I wanted to let you know that I haven't forgotten about you: I just
don't quite have a good answer to the latest issue. I'm not sure why
it is only processing one email, and not the others. It sounds very
much like it is installed correctly... So, I'm going to go through the
settings on my install and try it myself (sending about 10 test
messages) to see what happens. I'll let you know what I find out.
Thanks,
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
29 Dec 2002 19:53 PST
I checked the log again and it addded specific error messages:
"Temporary error 249 (temporary MX resolution error)" for each of the
emails that failed to send
|
Clarification of Answer by
legolas-ga
on
29 Dec 2002 23:21 PST
ahh.. There's the rub. It's a DNS error. It's actually possible that
the domains that you are sending to have messed up DNS MX entries.
That error is entirely outside of your ability to fix (or mine to help
you fix). It's cause is that the DNS for the domain you wish to send
to has an error in their DNS entry for the "Mail Exchange (MX)" entry.
Can you confirm for me if the test-mails that failed were destined for
AOL? AOL had a nasty habit of messing up their MX records in strange
ways. Many SMTP mailers include code that *specifically* deals with
AOL differently than ALL OTHER hosts! My Qmail install (a very
sophisticated mailer) actually needs to be patched -- just for AOL. I
have a sneaking suspicion that AOL has some part to play in your
errors. I found an interesting discussion on Google Groups about this
at:
http://groups.google.com/groups?q=mercury%27s+aol+mx&hl=en&lr=&ie=UTF-8&selm=3af58ff1.83906310%40news.CIS.DFN.DE&rnum=1
Please let me know, and I'll see what I can do... Although, I have to
add, it may be beyond my control to help on this particular issue....
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
30 Dec 2002 07:15 PST
Hmmm, no aol accounts involved anywhere in the process - I've never
had one and haven't used for any of the testing so far. My test
accounts have been 1) personal yahoo account 2) business yahoo account
3) school account 4) work account
If the problem were at the account's end rather than my end then 1) I
wouldn't expect it to affect multiple accounts and 2) I would expect
emails sent to that account from other accounts to have the same
problem (i.e. problem is sending to a "trouble" account rather than
from a "trouble" account).
The only common factor in the email sending errors is that sending
through localhost frequently produces errors and lost emails. I can
go through the same sending process in Outlook using an account set up
with my Yahoo SMTP rather than local host and everything sends just
fine.
Hope this helps.
|
Clarification of Answer by
legolas-ga
on
30 Dec 2002 09:15 PST
I'm stumped. Typically, if an SMTP mailer can send one message, it can
send them all. I looked through the settings and found nothing of
interest. I'd like you to turn on all logging in the software, run
your test again, and post the logs. Please take care to go through the
logs and remove any personally identifying information (i.e. email
addresses, etc.)
I will go through the logs and hopefully figure out the final hurdle
in this problem. I am convinced it is a badly behaving DNS server,
but, we'll see...
Legolas-ga
|
Clarification of Answer by
legolas-ga
on
30 Dec 2002 10:27 PST
From the Mercury Mail FAQ:
Problem: I am using the MercuryE end-to-end delivery module but it's
failing to deliver to some addresses I know are good.
Solution: If your workstation connects to the Internet via a dialup
connection, or if it uses DHCP to determine its IP address, you will
have to configure MercuryE explicitly to use a specific name server
via its configuration dialog. MercuryE sometimes cannot determine a
name server automatically on dialup or DHCP-configured systems.
It is definately a DNS issue as I suspected... A possible solution
would be for you to install BIND on your machine and point Mercury's
Name Service (that field we filled in before with IP addresses) to
127.0.0.1 once installed. That should fix the problem. Here's is
BIND's download page:
http://www.isc.org/products/BIND/bind9.html
and BIND for Win32 is located here:
ftp://ftp.isc.org/isc/bind/contrib/ntbind-9.2.1/BIND9.2.1.zip
The BIND homepage is here:
http://www.isc.org/products/BIND/
Installing and configuring BIND should be easy to do.. Follow the
directions provided. Since you only need a Caching name server,
installation and configuration should be the default settings for most
everything.
This should fix your problem. (and you thought SMTP would be easy to
deal with :) )
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
30 Dec 2002 18:37 PST
I installed bind and set the Mercury E to 127.0.0.1 - now no emails
will send. Bind had a simple installation process - one screen from
executable file, but the readme seems to indicate configuration
choices that must be done from DOS. The excerpt below from the
Readme makes me wonder if Bind must be pointed to localhost through
Dos? Also below are the scrubbed logs from Mercury. It's amazing how
challending simply sending emails can be ;) - Nick37-ga
IMPORTANT NOTE ON USING THE TOOLS:
If you wish to use nsupdate on a win32 platform to do dynamic updates
to a zone you MUST create a resolv.conf in the System32\Drivers\etc
directory containing a list of nameserver addresses to use to find
the nameserver authorative for the zone. The format of this file is:
nameserver 1.2.3.4
nameserver 5.6.7.8
LOGS (NOTE THERE ARE TWO LOGS BELOW)
MERCURYS.LOG
T 20021227 020453 3e0bb535 Connection from 127.0.0.1
T 20021227 020523 3e0bb535 Connection closed with 127.0.0.1, 30 sec.
elapsed.
T 20021227 020732 3e0bb536 Connection from 127.0.0.1
T 20021227 020802 3e0bb536 Connection closed with 127.0.0.1, 30 sec.
elapsed.
T 20021227 020923 3e0bb537 Connection from 127.0.0.1
T 20021227 020923 3e0bb537 HELO PCNAME
T 20021227 020923 3e0bb537 MAIL FROM: <user@domains.com>
T 20021227 020923 3e0bb537 RCPT TO: <user@domains.com>
E 20021227 020923 3e0bb537 Relay attempt by 127.0.0.1: from
<user@domains.com> to <user@domains.com>.
T 20021227 020923 3e0bb537 QUIT
T 20021227 020923 3e0bb537 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 021133 3e0bb538 Connection from 127.0.0.1
T 20021227 021133 3e0bb538 HELO PCNAME
T 20021227 021133 3e0bb538 MAIL FROM: <user@domains.com>
T 20021227 021133 3e0bb538 RCPT TO: <user@domains.com>
E 20021227 021134 3e0bb538 Relay attempt by 127.0.0.1: from
<user@domains.com> to <user@domains.com>.
T 20021227 021134 3e0bb538 QUIT
T 20021227 021134 3e0bb538 Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021227 021710 3e0bb539 Connection from 127.0.0.1
T 20021227 021710 3e0bb539 HELO PCNAME
T 20021227 021710 3e0bb539 MAIL FROM: <user@domains.com>
T 20021227 021710 3e0bb539 RCPT TO: <user@domains.com>
E 20021227 021710 3e0bb539 Relay attempt by 127.0.0.1: from
<user@domains.com> to <user@domains.com>.
T 20021227 021710 3e0bb539 QUIT
T 20021227 021710 3e0bb539 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 151842 3e0c6b14 Connection from 127.0.0.1
T 20021227 151842 3e0c6b14 HELO PCNAME
T 20021227 151842 3e0c6b14 MAIL FROM: <user@domains.com>
T 20021227 151842 3e0c6b14 RCPT TO: <user@domains.com>
T 20021227 151842 3e0c6b14 DATA - 16 lines, 500 bytes.
T 20021227 151844 3e0c6b14 QUIT
T 20021227 151844 3e0c6b14 Connection closed with 127.0.0.1, 2 sec.
elapsed.
T 20021227 153258 3e0c6b15 Connection from 127.0.0.1
T 20021227 153258 3e0c6b15 HELO PCNAME
T 20021227 153258 3e0c6b15 MAIL FROM: <user@domains.com>
T 20021227 153258 3e0c6b15 RCPT TO: <user@domain.com>
T 20021227 153258 3e0c6b15 DATA - 55 lines, 1275 bytes.
T 20021227 153258 3e0c6b15 QUIT
T 20021227 153258 3e0c6b15 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 153644 3e0c6b16 Connection from 127.0.0.1
T 20021227 153644 3e0c6b16 HELO PCNAME
T 20021227 153644 3e0c6b16 MAIL FROM: <user@domains.com>
T 20021227 153644 3e0c6b16 RCPT TO: <user@domain.com>
T 20021227 153644 3e0c6b16 DATA - 70 lines, 1673 bytes.
T 20021227 153644 3e0c6b16 QUIT
T 20021227 153644 3e0c6b16 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 153925 3e0c6b17 Connection from 127.0.0.1
T 20021227 153925 3e0c6b17 HELO PCNAME
T 20021227 153926 3e0c6b17 MAIL FROM: <user@domains.com>
T 20021227 153926 3e0c6b17 RCPT TO: <we5mills@worldnet.att.net>
T 20021227 153926 3e0c6b17 DATA - 130 lines, 4794 bytes.
T 20021227 153926 3e0c6b17 QUIT
T 20021227 153926 3e0c6b17 Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021227 154132 3e0c6b18 Connection from 127.0.0.1
T 20021227 154132 3e0c6b18 HELO PCNAME
T 20021227 154132 3e0c6b18 MAIL FROM: <user@domains.com>
T 20021227 154132 3e0c6b18 RCPT TO: <user@domains.com>
T 20021227 154132 3e0c6b18 DATA - 16 lines, 505 bytes.
T 20021227 154132 3e0c6b18 QUIT
T 20021227 154132 3e0c6b18 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 154350 3e0c6b19 Connection from 127.0.0.1
T 20021227 154350 3e0c6b19 HELO PCNAME
T 20021227 154350 3e0c6b19 MAIL FROM: <user@domains.com>
T 20021227 154350 3e0c6b19 RCPT TO: <user@domain.com>
T 20021227 154350 3e0c6b19 DATA - 16 lines, 498 bytes.
T 20021227 154350 3e0c6b19 QUIT
T 20021227 154350 3e0c6b19 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 161533 3e0c7660 Connection from 127.0.0.1
T 20021227 161533 3e0c7660 HELO PCNAME
T 20021227 161533 3e0c7660 MAIL FROM: <user@domains.com>
T 20021227 161533 3e0c7660 RCPT TO: <user@domain.com>
T 20021227 161533 3e0c7660 DATA - 16 lines, 492 bytes.
T 20021227 161533 3e0c7660 QUIT
T 20021227 161533 3e0c7660 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021227 222703 3e0c6b1a Connection from 127.0.0.1
T 20021227 222703 3e0c6b1a HELO PCNAME
T 20021227 222703 3e0c6b1a MAIL FROM: <user@domains.com>
T 20021227 222703 3e0c6b1a RCPT TO: <user@domain.com>
T 20021227 222703 3e0c6b1a DATA - 16 lines, 505 bytes.
T 20021227 222703 3e0c6b1a RSET
T 20021227 222703 3e0c6b1a MAIL FROM: <user@domains.com>
T 20021227 222703 3e0c6b1a RCPT TO: <user@domains.com>
T 20021227 222703 3e0c6b1a DATA - 16 lines, 505 bytes.
T 20021227 222703 3e0c6b1a RSET
T 20021227 222703 3e0c6b1a MAIL FROM: <user@domains.com>
T 20021227 222703 3e0c6b1a RCPT TO: <user@domain.com>
T 20021227 222703 3e0c6b1a DATA - 16 lines, 504 bytes.
T 20021227 222703 3e0c6b1a RSET
T 20021227 222703 3e0c6b1a MAIL FROM: <user@domains.com>
T 20021227 222703 3e0c6b1a RCPT TO: <user@domain.com>
T 20021227 222703 3e0c6b1a DATA - 16 lines, 499 bytes.
T 20021227 222703 3e0c6b1a QUIT
T 20021227 222703 3e0c6b1a Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021228 082610 3e0d5d38 Connection from 127.0.0.1
T 20021228 082610 3e0d5d38 HELO PCNAME
T 20021228 082610 3e0d5d38 MAIL FROM: <user@domains.com>
T 20021228 082610 3e0d5d38 RCPT TO: <user@domain.com>
T 20021228 082610 3e0d5d38 DATA - 26 lines, 748 bytes.
T 20021228 082610 3e0d5d38 RSET
T 20021228 082610 3e0d5d38 MAIL FROM: <user@domains.com>
T 20021228 082610 3e0d5d38 RCPT TO: <user@domain.com>
T 20021228 082610 3e0d5d38 DATA - 26 lines, 758 bytes.
T 20021228 082610 3e0d5d38 RSET
T 20021228 082610 3e0d5d38 MAIL FROM: <user@domains.com>
T 20021228 082610 3e0d5d38 RCPT TO: <user@domains.com>
T 20021228 082610 3e0d5d38 DATA - 26 lines, 777 bytes.
T 20021228 082611 3e0d5d38 RSET
T 20021228 082611 3e0d5d38 MAIL FROM: <user@domains.com>
T 20021228 082611 3e0d5d38 RCPT TO: <user@domain.com>
T 20021228 082611 3e0d5d38 DATA - 26 lines, 760 bytes.
T 20021228 082611 3e0d5d38 QUIT
T 20021228 082611 3e0d5d38 Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021228 083219 3e0d5d39 Connection from 127.0.0.1
T 20021228 083219 3e0d5d39 HELO PCNAME
T 20021228 083219 3e0d5d39 MAIL FROM: <user@domains.com>
T 20021228 083219 3e0d5d39 RCPT TO: <jill.vanderbush@northwestern.com>
T 20021228 083219 3e0d5d39 DATA - 78 lines, 2516 bytes.
T 20021228 083219 3e0d5d39 QUIT
T 20021228 083219 3e0d5d39 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021228 132818 3e0da69b Connection from 127.0.0.1
T 20021228 132818 3e0da69b HELO PCNAME
T 20021228 132818 3e0da69b MAIL FROM: <user@domains.com>
T 20021228 132818 3e0da69b RCPT TO: <user@domains.com>
T 20021228 132818 3e0da69b DATA - 16 lines, 500 bytes.
T 20021228 132818 3e0da69b QUIT
T 20021228 132818 3e0da69b Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021228 133009 3e0da69c Connection from 127.0.0.1
T 20021228 133009 3e0da69c HELO PCNAME
T 20021228 133009 3e0da69c MAIL FROM: <user@domains.com>
T 20021228 133009 3e0da69c RCPT TO: <user@domains.com>
T 20021228 133009 3e0da69c DATA - 16 lines, 505 bytes.
T 20021228 133009 3e0da69c QUIT
T 20021228 133009 3e0da69c Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021228 215038 3e0da69d Connection from 127.0.0.1
T 20021228 215038 3e0da69d HELO PCNAME
T 20021228 215038 3e0da69d MAIL FROM: <user@domains.com>
T 20021228 215038 3e0da69d RCPT TO: <user@domains.com>
T 20021228 215038 3e0da69d DATA - 16 lines, 505 bytes.
T 20021228 215038 3e0da69d QUIT
T 20021228 215038 3e0da69d Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021228 215232 3e0da69e Connection from 127.0.0.1
T 20021228 215232 3e0da69e HELO PCNAME
T 20021228 215232 3e0da69e MAIL FROM: <user@domains.com>
T 20021228 215232 3e0da69e RCPT TO: <user@domain.com>
T 20021228 215232 3e0da69e DATA - 35 lines, 945 bytes.
T 20021228 215232 3e0da69e RSET
T 20021228 215232 3e0da69e MAIL FROM: <user@domains.com>
T 20021228 215232 3e0da69e RCPT TO: <user@domains.com>
T 20021228 215232 3e0da69e DATA - 35 lines, 949 bytes.
T 20021228 215232 3e0da69e RSET
T 20021228 215232 3e0da69e MAIL FROM: <user@domains.com>
T 20021228 215232 3e0da69e RCPT TO: <user@domain.com>
T 20021228 215232 3e0da69e DATA - 35 lines, 942 bytes.
T 20021228 215232 3e0da69e RSET
T 20021228 215232 3e0da69e MAIL FROM: <user@domains.com>
T 20021228 215232 3e0da69e RCPT TO: <user@domain.com>
T 20021228 215232 3e0da69e DATA - 35 lines, 927 bytes.
T 20021228 215232 3e0da69e QUIT
T 20021228 215232 3e0da69e Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021228 215500 3e0da69f Connection from 127.0.0.1
T 20021228 215500 3e0da69f HELO PCNAME
T 20021228 215500 3e0da69f MAIL FROM: <user@domains.com>
T 20021228 215500 3e0da69f RCPT TO: <user@domains.com>
T 20021228 215500 3e0da69f DATA - 16 lines, 505 bytes.
T 20021228 215500 3e0da69f QUIT
T 20021228 215500 3e0da69f Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021229 214916 3e0da6a0 Connection from 127.0.0.1
T 20021229 214916 3e0da6a0 HELO PCNAME
T 20021229 214916 3e0da6a0 MAIL FROM: <user@domains.com>
T 20021229 214916 3e0da6a0 RCPT TO: <user@domain.com>
T 20021229 214916 3e0da6a0 DATA - 64 lines, 2052 bytes.
T 20021229 214916 3e0da6a0 QUIT
T 20021229 214916 3e0da6a0 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021230 185847 3e109678 Connection from 127.0.0.1
T 20021230 185847 3e109678 HELO PCNAME
T 20021230 185847 3e109678 MAIL FROM: <user@domains.com>
T 20021230 185847 3e109678 RCPT TO: <user@domains.com>
T 20021230 185847 3e109678 DATA - 39 lines, 1209 bytes.
T 20021230 185847 3e109678 QUIT
T 20021230 185847 3e109678 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021230 194012 3e109679 Connection from 127.0.0.1
T 20021230 194012 3e109679 HELO PCNAME
T 20021230 194012 3e109679 MAIL FROM: <user@domains.com>
T 20021230 194012 3e109679 RCPT TO: <user@domains.com>
T 20021230 194012 3e109679 DATA - 39 lines, 1209 bytes.
T 20021230 194012 3e109679 QUIT
T 20021230 194012 3e109679 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021230 194117 3e10967a Connection from 127.0.0.1
T 20021230 194117 3e10967a HELO PCNAME
T 20021230 194117 3e10967a MAIL FROM: <user@domains.com>
T 20021230 194117 3e10967a RCPT TO: <user@domain.com>
T 20021230 194117 3e10967a DATA - 39 lines, 1208 bytes.
T 20021230 194117 3e10967a QUIT
T 20021230 194118 3e10967a Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 194539 3e10967b Connection from 127.0.0.1
T 20021230 194539 3e10967b HELO PCNAME
T 20021230 194539 3e10967b MAIL FROM: <user@domains.com>
T 20021230 194539 3e10967b RCPT TO: <user@domain.com>
T 20021230 194540 3e10967b DATA - 39 lines, 1202 bytes.
T 20021230 194540 3e10967b QUIT
T 20021230 194540 3e10967b Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 194548 3e10967c Connection from 127.0.0.1
T 20021230 194548 3e10967c HELO PCNAME
T 20021230 194548 3e10967c MAIL FROM: <user@domains.com>
T 20021230 194548 3e10967c RCPT TO: <user@domain.com>
T 20021230 194548 3e10967c DATA - 39 lines, 1202 bytes.
T 20021230 194548 3e10967c QUIT
T 20021230 194549 3e10967c Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 195112 3e10967d Connection from 127.0.0.1
T 20021230 195112 3e10967d HELO PCNAME
T 20021230 195112 3e10967d MAIL FROM: <user@domains.com>
T 20021230 195112 3e10967d RCPT TO: <user@domains.com>
T 20021230 195113 3e10967d DATA - 39 lines, 1209 bytes.
T 20021230 195113 3e10967d QUIT
T 20021230 195113 3e10967d Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 195411 3e10967e Connection from 127.0.0.1
T 20021230 195412 3e10967e HELO PCNAME
T 20021230 195412 3e10967e MAIL FROM: <user@domains.com>
T 20021230 195412 3e10967e RCPT TO: <user@domains.com>
T 20021230 195412 3e10967e DATA - 39 lines, 1237 bytes.
T 20021230 195412 3e10967e QUIT
T 20021230 195412 3e10967e Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 200327 3e10a656 Connection from 127.0.0.1
T 20021230 200328 3e10a656 HELO PCNAME
T 20021230 200328 3e10a656 MAIL FROM: <user@domains.com>
T 20021230 200328 3e10a656 RCPT TO: <user@domains.com>
T 20021230 200328 3e10a656 DATA - 39 lines, 1209 bytes.
T 20021230 200328 3e10a656 QUIT
T 20021230 200328 3e10a656 Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 200415 3e10a657 Connection from 127.0.0.1
T 20021230 200415 3e10a657 HELO PCNAME
T 20021230 200415 3e10a657 MAIL FROM: <user@domains.com>
T 20021230 200415 3e10a657 RCPT TO: <user@domain.com>
T 20021230 200416 3e10a657 DATA - 39 lines, 1208 bytes.
T 20021230 200416 3e10a657 QUIT
T 20021230 200416 3e10a657 Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 200550 3e10a658 Connection from 127.0.0.1
T 20021230 200550 3e10a658 HELO PCNAME
T 20021230 200550 3e10a658 MAIL FROM: <user@domains.com>
T 20021230 200550 3e10a658 RCPT TO: <user@domain.com>
T 20021230 200550 3e10a658 DATA - 39 lines, 1208 bytes.
T 20021230 200550 3e10a658 QUIT
T 20021230 200550 3e10a658 Connection closed with 127.0.0.1, 0 sec.
elapsed.
T 20021230 200623 3e10a72b Connection from 127.0.0.1
T 20021230 200623 3e10a72b HELO PCNAME
T 20021230 200623 3e10a72b MAIL FROM: <user@domains.com>
T 20021230 200623 3e10a72b RCPT TO: <user@domain.com>
T 20021230 200623 3e10a72b DATA - 39 lines, 1208 bytes.
T 20021230 200624 3e10a72b QUIT
T 20021230 200624 3e10a72b Connection closed with 127.0.0.1, 1 sec.
elapsed.
T 20021230 200838 3e10a72c Connection from 127.0.0.1
T 20021230 200838 3e10a72c HELO PCNAME
T 20021230 200838 3e10a72c MAIL FROM: <user@domains.com>
T 20021230 200838 3e10a72c RCPT TO: <user@domains.com>
T 20021230 200838 3e10a72c DATA - 39 lines, 1202 bytes.
T 20021230 200838 3e10a72c QUIT
T 20021230 200838 3e10a72c Connection closed with 127.0.0.1, 0 sec.
elapsed.
MERCURYE.LOG
T 20021230 185904 3e10ead8 Begin processing job MO000002 from
user@domains.com
T 20021230 185907 3e10ead8 Established ESMTP connection to IPADDRESS
T 20021230 185907 3e10ead8 MAIL FROM:<user@domains.com> SIZE=1400
T 20021230 185908 3e10ead8 250 2.1.0 user@domains.com....Sender OK
T 20021230 185908 3e10ead8 RCPT TO:<user@domains.com>
T 20021230 185908 3e10ead8 250 2.1.5 user@domains.com
T 20021230 185909 3e10ead8 Connection closed normally.
T 20021230 185910 3e10ead8 Job MO000002 processing complete.
T 20021230 194024 3e10ead9 Begin processing job MO000004 from
user@domains.com
T 20021230 194027 3e10ead9 Established ESMTP connection to IPADDRESS
T 20021230 194027 3e10ead9 MAIL FROM:<user@domains.com> SIZE=1400
T 20021230 194027 3e10ead9 250 2.1.0 user@domains.com....Sender OK
T 20021230 194027 3e10ead9 RCPT TO:<user@domains.com>
T 20021230 194027 3e10ead9 250 2.1.5 user@domains.com
T 20021230 194029 3e10ead9 Connection closed normally.
T 20021230 194029 3e10ead9 Job MO000004 processing complete.
T 20021230 194128 3e10eada Begin processing job MO000006 from
user@domains.com
T 20021230 194130 3e10eada Established ESMTP connection to
66.163.171.159
T 20021230 194130 3e10eada MAIL FROM:<user@domains.com> SIZE=1399
T 20021230 194131 3e10eada 250 sender <user@domains.com> ok
T 20021230 194131 3e10eada RCPT TO:<user@domain.com>
T 20021230 194131 3e10eada 250 recipient <user@domain.com> ok
T 20021230 194133 3e10eada Connection closed normally.
T 20021230 194133 3e10eada Job MO000006 processing complete.
T 20021230 194600 3e10eadb Begin processing job MO000008 from
user@domains.com
T 20021230 194600 3e10eadc Begin processing job MO00000A from
user@domains.com
T 20021230 194615 3e10eadc Established ESMTP connection to
128.135.130.121
T 20021230 194615 3e10eadc MAIL FROM:<user@domains.com> SIZE=1393
T 20021230 194618 3e10eadc 250 2.5.0 Address and options OK.
T 20021230 194618 3e10eadc RCPT TO:<user@domain.com>
T 20021230 194620 3e10eadc 250 2.1.5 user@domain.com OK.
T 20021230 194625 3e10eadc Connection closed normally.
T 20021230 194628 3e10eadc Job MO00000A processing complete.
T 20021230 194643 3e10eadb Established ESMTP connection to
64.156.215.5
T 20021230 194643 3e10eadb MAIL FROM:<user@domains.com> SIZE=1393
T 20021230 194647 3e10eadb 250 sender <user@domains.com> ok
T 20021230 194648 3e10eadb RCPT TO:<user@domain.com>
T 20021230 194652 3e10eadb 250 recipient <user@domain.com> ok
T 20021230 194703 3e10eadb Connection closed normally.
T 20021230 194709 3e10eadb Job MO000008 processing complete.
T 20021230 195121 3e10eadd Begin processing job MO00000C from
user@domains.com
W 20021230 195121 3e10eadd Temporary error 249 (temporary MX
resolution error) resolving 'domains.com'.
T 20021230 195121 3e10eadd Job MO00000C processing complete.
T 20021230 195417 3e10eade Begin processing job MO00000E from
user@domains.com
W 20021230 195417 3e10eade Temporary error 249 (temporary MX
resolution error) resolving 'domains.com'.
T 20021230 195417 3e10eade Job MO00000E processing complete.
T 20021230 200351 3e10fab7 Begin processing job MO000002 from
user@domains.com
W 20021230 200351 3e10fab7 Temporary error 249 (temporary MX
resolution error) resolving 'domains.com'.
T 20021230 200351 3e10fab7 Job MO000002 processing complete.
T 20021230 200423 3e10fab8 Begin processing job MO000004 from
user@domains.com
W 20021230 200423 3e10fab8 Temporary error 249 (temporary MX
resolution error) resolving 'domain.com'.
T 20021230 200423 3e10fab8 Job MO000004 processing complete.
T 20021230 200615 3e10fab9 Begin processing job MO000006 from
user@domains.com
W 20021230 200615 3e10fab9 Temporary error 249 (temporary MX
resolution error) resolving 'domain.com'.
T 20021230 200615 3e10fab9 Job MO000006 processing complete.
T 20021230 200631 3e10faba Begin processing job MO001310 from
user@domains.com
W 20021230 200631 3e10faba Temporary error 249 (temporary MX
resolution error) resolving 'domain.com'.
T 20021230 200631 3e10faba Job MO001310 processing complete.
T 20021230 200855 3e10fabb Begin processing job MO000007 from
user@domains.com
W 20021230 200855 3e10fabb Temporary error 249 (temporary MX
resolution error) resolving 'domains.com'.
T 20021230 200855 3e10fabb Job MO000007 processing complete.
T 20021230 202127 3e10fabc Begin processing job MO00000C from
user@domains.com
W 20021230 202127 3e10fabc Temporary error 249 (temporary MX
resolution error) resolving 'domains.com'.
T 20021230 202127 3e10fabc Job MO00000C processing complete.
Replace the IP addresses with your real addresses. 127.0.0.1 is a
valid
address if you are running a nameserver on the localhost.
|
Request for Answer Clarification by
nick37-ga
on
30 Dec 2002 19:20 PST
The last three lines above go with the Bind instructions rather than the log
|
Clarification of Answer by
legolas-ga
on
30 Dec 2002 21:55 PST
<sigh> It is so much a DNS error. At the hope of convincing you that
this is not the panacea you thought it would be, let me tell you that
even IF we get this to work 100% perfectly, the bottom line is that I
doubt that it will EVER be better/faster than sending it through any
public or private SMTP server you have access to. If a message is
100k, it will either take "x" time to upload it to your corporate
mailserver, or "x" time to upload it to the yahoo SMTP server you were
using or, "x" time to upload it yourself to whatever host you are
sending the message to.
However, given that it is absolutely a DNS error: and one that is
probably based on a DNS table for a domain being too large for your
current DNS server to resolve correctly, I am really struggling for a
solution.
I have asked Google Answers for permission to contact you directly and
hopefully resolve this issue via. other methods (i.e. remote access of
your PC), but, since right now, that would violate our
terms-of-service, I have to wait for the green-light (of course, I
have no idea if you are ok with that option either!).
I will mull on a possible solution overnight, and try to get back to
you with another option to try tommorow.. But, I am quickly running
out of solutions. Honestly, I'm now wondering if the viruses you had
have somehow affected your computers' ability to correctly process DNS
information. Or, the fact that your IP is dynamic and assigned by DHCP
could also play a large role in the problems...
I will get back to you shortly... Hang tough! :)
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
31 Dec 2002 06:15 PST
Legolas,
I appreciate your persistence. I'm also starting to get concerned re:
localhost. Specifically that it is so far past my knowledge base that
even after we set it up, there could be problems that arise that are
invisible to me. I use spreadsheets a lot and sometimes have to set
people up with answers that are simpler than the ideal, just so they
have a clue if something changes or hiccups.
I really wouldn't mind using yahoo to send if people couldn't tell it
was yahoo (i.e. it looked to the recipients just as if I were using
the corporate account). I think this may be the "domain masquerade"
allowed by Win 2000 SMTP. Is a better answer finding a public SMTP
(maybe not yahoo if they don't have that feature, but possibly a
different one)that will let me mask the domain? I don't even mind
paying a reasonable subscription fee Since I'm used to using pop3
style mail, that would be more intuitive to me (i.e. if something
hiccuped, I might have a clue).
I'd be glad to talk with you directly. I can't give you remote access
simply because it is a company pc, but would be glad to call you on my
nickel. We may be able to walk through in a few minutes over the
phone what could take days by message posting. I'm not concerned
about you having any personal info, but understand the wisdom of not
posting it publicly.
Let me know what you think.
Best, - nick37
|
Clarification of Answer by
legolas-ga
on
31 Dec 2002 10:42 PST
There is a third, intervening variable, that is affecting the
resolution of this matter. There is something about the way your
computer is networked or the ISP you use that is causing the SMTP
installation to fail. I have completely run out of ideas for possible
solution.
I will completely understand if you would like to ask for a refund of
the question price: you can do so by writing to
answers-editors@google.com and either requesting a refund or that the
question be reposted. However, other than trying a completely
different method of doing SMTP (for example, going back to trying to
install Microsoft's SMTP server--which will probably have just as many
strange issues), I don't think there is a 'good' solution to this
problem. However, you should know that I will be paid less money than
I would otherwise be paid for this question should you request a
refund.
Quite simply, Mercury is setup correctly from what I can see. There is
no reason other than the DNS errors that is preventing your messages
from being delivered. However, solving DNS errors, and generally
debugging your network connection is far beyond the original scope of
this question. And.. Even if I *DID* attempt to do those things,
because you are using SMTP in a way that it was really never totally
intentioned on being used, I still can't guarantee any more success
than what we currently have obtained.
My install of Mercury works like a trooper. There does not seem to be
any easy fix at this time.
Also, you are entirely right--maintaining an SMTP installation (and
email servers in general) are not for the faint of heart. It is
entirely possible and even likely that the install will need
maintenance in the future: maintenance that you are not skilled to
provide. For the sake of speed, you may be trading an awful lot of
your time and money... And, quite frankly, I question how much faster
your own SMTP server could be vs. sending it through your corporate
server...
Sorry... :(
Legolas-ga
|
Request for Answer Clarification by
nick37-ga
on
02 Jan 2003 08:05 PST
Legolas,
Thanks for all your help. You've been amazingly persistent and I
appreciate your expertise. I think we came to the right answer - that
the solutions we were considering were beyond me technically.
I've gone with what may be a 95% solution. I've created a fastmail
account (for about $10-$20/yr) that allows me pop/smtp access and
masks the "from" domain. So far it has worked well. I receive on the
work account, send on the fastmail account. Anyone receiving sees
only the work account - so no confusion is created.
God Bless in the New Year!
-Nick37-ga
|
Clarification of Answer by
legolas-ga
on
02 Jan 2003 09:03 PST
Thanks so much for the rating and the tip. The best to you and yours
in the New Year!
Legolas-ga
|
