What could be blocking Sendmail?

I was at a client site today and I wasn't able to send any email from my
laptop. They claim that they aren't blocking any outgoing ports but
Sendmail wasn't able to send anything while I was there. When I got home
and hooked up to my own network all of my messages were sent. The client's
network has a Windows mail server on it and it's able to send mail so I
don't think that Verizon is blocking any ports on the DSL line. Does
anyone have any ideas what might be happening?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.networking General Schvantzkoph <(E-Mail Removed)> suggested:
> I was at a client site today and I wasn't able to send any email from my
> laptop. They claim that they aren't blocking any outgoing ports but
> Sendmail wasn't able to send anything while I was there. When I got home
[..]

Many possibilities, at first, check /var/log/mail* or wherever
sendmail logs on your system, post the relevant lines, if it
doesn't make any sense to you and we will see.

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAmzVDAkPEju3Se5QRArwVAKDTT5K67EigvyWCaz43f7 tYmLuOrwCgowxI
iYRF7MoGp1ceOcv3QoSN158=
=8vWf
-----END PGP SIGNATURE-----

General Schvantzkoph <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> I was at a client site today and I wasn't able to send any email from my
> laptop. They claim that they aren't blocking any outgoing ports but
> Sendmail wasn't able to send anything while I was there. When I got home
> and hooked up to my own network all of my messages were sent. The client's
> network has a Windows mail server on it and it's able to send mail so I
> don't think that Verizon is blocking any ports on the DSL line. Does
> anyone have any ideas what might be happening?

In addition to the log messages, as M.H. suggests, you might want to
sniff the wire as you're sending mail out and see the connection
sequence -- my guess is that your Sendmail is not authorized to relay
through their mailer.

Since you didn't mention any returned errors, however, it's not clear
what the problem might be -- usually mailers will return a "useful"
error of some sort. It might be an authentication failure -- the sort
of error that some providers don't return on the theory that no info
is better than leaking info via error messages.

Many broadband providers are beginning to really tighten up on mail
relaying in the war on spam -- the assumption is that clients can't be
trusted to properly set up their MTAs without explicit
help/authorization from the provider.

Just curious, were other internet services available on your laptop --
ie., web browsing?

hth,
prg
email above disabled

On Fri, 07 May 2004 08:05:24 -0700, P Gentry wrote:

> General Schvantzkoph <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> I was at a client site today and I wasn't able to send any email from my
>> laptop. They claim that they aren't blocking any outgoing ports but
>> Sendmail wasn't able to send anything while I was there. When I got home
>> and hooked up to my own network all of my messages were sent. The client's
>> network has a Windows mail server on it and it's able to send mail so I
>> don't think that Verizon is blocking any ports on the DSL line. Does
>> anyone have any ideas what might be happening?
>
> In addition to the log messages, as M.H. suggests, you might want to
> sniff the wire as you're sending mail out and see the connection
> sequence -- my guess is that your Sendmail is not authorized to relay
> through their mailer.
>
> Since you didn't mention any returned errors, however, it's not clear
> what the problem might be -- usually mailers will return a "useful"
> error of some sort. It might be an authentication failure -- the sort
> of error that some providers don't return on the theory that no info
> is better than leaking info via error messages.
>
> Many broadband providers are beginning to really tighten up on mail
> relaying in the war on spam -- the assumption is that clients can't be
> trusted to properly set up their MTAs without explicit
> help/authorization from the provider.
>
> Just curious, were other internet services available on your laptop --
> ie., web browsing?
>
> hth,
> prg
> email above disabled

The DSL line is a business class line which permits the use of mail
servers, and as I've pointed out the client is running a Windows based
mail server which is working fine. I looked in the log files and didn't
see any thing suspicious however I'll check them again the next time I'm
at that site. I'll check all of the logs, then send an e-mail, and then
see which new messages appear.

Web browsing and reading mail (which I pull from an external pop server)
all work fine.

General Schvantzkoph wrote:

> The DSL line is a business class line which permits the use of mail
> servers, and as I've pointed out the client is running a Windows based
> mail server which is working fine. I looked in the log files and didn't
> see any thing suspicious however I'll check them again the next time I'm
> at that site. I'll check all of the logs, then send an e-mail, and then
> see which new messages appear.
>

Try tail -f logfile, then send message

--
Why should your dreams not be beautiful?
Why should you not believe in your dreams?

General Schvantzkoph <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
[snip]
>
> The DSL line is a business class line which permits the use of mail
> servers, and as I've pointed out the client is running a Windows based
> mail server which is working fine. I looked in the log files and didn't
> see any thing suspicious however I'll check them again the next time I'm
> at that site. I'll check all of the logs, then send an e-mail, and then
> see which new messages appear.
>
> Web browsing and reading mail (which I pull from an external pop server)
> all work fine.

This is what I guessed -- and why I suggested actually sniffing your
smtp traffic when trying to send mail via your MTA.

My ISP (actually their upstream provider) uses Communigate and it is
set to require their business class customers running their own MTAs
to negotiate an authentication sequence before relaying their mail.
Failures are simply dropped -- no error returns, no nothing most of
the time.

There can be other issues also, but I find sniffing the quickest way
to pinpoint the likely problem -- not always of course ;-(

My experience with tech support re: mail lately has not been very,
shall we say, "informative". Tempted to say "clueless" but can't
blame the guys in the trenches -- I've been there too many times
myself. Had to read through the Comminigate docs myself to find the
source of the problem.

Good luck,
prg
email above disabled