pdp at exim
Jun 3, 2012, 7:24 AM
Post #3 of 4
On 2012-06-03 at 09:58 -0400, Phil Pennock wrote:
> Variable: still not quite sure about exposing this, or if perhaps it
> should be an expansion item rather than a variable, so that each time
> it's expanded the value is fetched. Er, I'm also blanking on how to
> *implement* this with a read()-based API, without switching our entire
> SMTP read system to a readmsg()-based system, which I'm *very* reluctant
> to do for such a minor feature.
Stevens, Unix Network Programming, volume 1 3rd edition (Stevens,
Fenner, Rudoff), page 215, under "IP_TOS Socket Option":
This option lets us set the type-of-service (TOS) field (which
contains the DSCP and ECN fields, Figure A.1) in the IP header for a
TCP, UDP or SCTP socket. If we call getsockopt for this option, the
current value that would be placed into the DSCP and ECN fields in the
IP header (which defaults to 0) is returned. There is no way to fetch
the value from a received IP datagram.
That last sentence clinches it, there will not be a
$received_initial_dscp or $received_dscp added to Exim.
As to ECN/DSCP bit fields, the second-next paragraph notes that the ECN
field should be specified as zero in the setsockopt value set with
Okay, that's that sorted. Someone who wants to distinguish inbound DSCP
values needs to enumerate the values they care about, have Exim listen
on multiple ports and have the router or system kernel packet filter
redirect to an appropriate port based upon DSCP in the inbound SYN
packet and maintain the flow thereafter, even if the DSCP value changes.
Fortunately, the MTA use-case for DSCP which I designed at
$a_former_employer only needs DSCP for outbound connections.
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##