At 12:33 AM 5/30/2007, you wrote:
On Tue, 29 May 2007 14:24 -0700, ipfilter wrote:
Personaly "dont know if you will like this approach to the matter..."
but I would add a rule to the top of this file specificly for smtp
traffic just during your testing phase (debug) of your ruleset.
pass out quick on %IFACE% from %IP/MASK% to any port = 25 keep state
and then test that rule by sending out some mail to the place its not
going to. If mail has not been sent out then the problem is more than
likely with the port "maybe (smtps:465)". You might also have to
unblock (submission:587). Now if your mail goes through then just move
that rule down by 1 and test again untill your mail does not go through
and then youll know at least which rule is effecting your transfers.
Thanks, I'm trying this now, but in the reverse - I put the rule in
just above the existing smtp rule, and I'm moving it up one for each
try. Why? I've sent a message with attachment to one of the
correspondents - but it's not my own correspondent. I don't want to
send a whole series of messages to this poor person while I debug -
so going in the reverse order, it'll fail repeatedly unless and until
it works, rather than working, working, working, until it fails. Does
that makes sense?
Preferably I would ublock out:25,587 and add keep state to both of those
with no flags for the meantime or at least add flags S keep state.
Dont know how much help this will be to you but at the moment I dont
have time to type much more as Im trying allready to do to many things
at-once "multi-tasking is way overrated". Any way this should at
least give you a start. Note: Definately focus on 25 & 587 seperate
or together.
Port 587 can't be involved - this is a problem with mail transport
between two MX servers, not between user and MX server. Right now,
the mail with attachment is sitting in my server's queue, waiting for
the att/sbcglobal/pacbell MX servers to accept it - and that traffic
will only go over port 25.
Thanks for the suggestion above however, it provides a good
methodology for tracking this down...
Paul Theodoropoulos
http://www.anastrophe.com
