On Feb 18, 2:33am, [email protected] wrote:
} --- On Tue, 11/2/10, David F. Skoll <[email protected]> wrote:
} > I guess I mis-wrote.=A0 I meant making the client port available.
} > As for the server port, it's too difficult to pass that in at
} > filter_connect time.
}
} The server port is already "known" because it is tied to the "daemon_name"
} variable which is passed at the xxfi_connect() call.
}
} In Sendmail, this comes from the DAEMON_OPTIONS() M4 configuration
} directive. The field "name=3D" is what is passed, and as that is
} tied to a field "port=", and all ports must be uniquely 1-to-1 mapped
} to names, passing the name implies the unique value of port.
}
} Pseudocode - NOT perl:
}
} switch($daemon_name) {
} case "MSA": Port=587; break;
} case "MTA": Port=25; break;
} case "MTS": Port=465; break;
} }
}
} If you can't do something like that to obtain the value you want from
} the value you're given, ....
No, you can't. A name does not imply a port. You could do it
based on knowledge of your sendmail.cf, but that wouldn't be very good
programming. Anyways, the problem is that mimedefang creates a
subdirectory with a name based on the QueueID then creates files in
that subdirectory for communicating with the filter (including listing
macros and their values). Since there is no QueueID at filter_relay()
time, it has no place to store information.
}-- End of excerpt from [email protected]
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
