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 IP_TOS. 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. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
