X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/3a7963704c5192e25046b1a2f808d4b8ed357386..40167b055c6f7c2168941524ca6af08674dfbbb7:/doc/doc-docbook/spec.xfpt diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt index f902fe856..d35c305c8 100644 --- a/doc/doc-docbook/spec.xfpt +++ b/doc/doc-docbook/spec.xfpt @@ -533,10 +533,23 @@ The &_.bz2_& file is usually a lot smaller than the &_.gz_& file. .cindex "distribution" "signing details" .cindex "distribution" "public key" .cindex "public key for signed distribution" -The distributions are currently signed with Nigel Metheringham's GPG key. The -corresponding public key is available from a number of keyservers, and there is -also a copy in the file &_nigel-pubkey.asc_&. The signatures for the tar bundles are -in: +.new +The distributions will be PGP signed by an individual key of the Release +Coordinator. This key will have a uid containing an email address in the +&'exim.org'& domain and will have signatures from other people, including +other Exim maintainers. We expect that the key will be in the "strong set" of +PGP keys. There should be a trust path to that key from Nigel Metheringham's +PGP key, a version of which can be found in the release directory in the file +&_nigel-pubkey.asc_&. All keys used will be available in public keyserver pools, +such as &'pool.sks-keyservers.net'&. + +At time of last update, releases were being made by Phil Pennock and signed with +key &'0x403043153903637F'&, although that key is expected to be replaced in 2013. +A trust path from Nigel's key to Phil's can be observed at +&url(https://www.security.spodhuis.org/exim-trustpath). +.wen + +The signatures for the tar bundles are in: .display &_exim-n.nn.tar.gz.asc_& &_exim-n.nn.tar.bz2.asc_& @@ -1348,6 +1361,8 @@ Setting the &%verify%& option actually sets two options, &%verify_sender%& and &%verify_recipient%&, which independently control the use of the router for sender and recipient verification. You can set these options directly if you want a router to be used for only one type of verification. +Note that cutthrough delivery is classed as a recipient verification +for this purpose. .next If the &%address_test%& option is set false, the router is skipped when Exim is run with the &%-bt%& option to test an address routing. This can be helpful @@ -1357,6 +1372,7 @@ having to simulate the effect of the scanner. .next Routers can be designated for use only when verifying an address, as opposed to routing it for delivery. The &%verify_only%& option controls this. +Again, cutthrough delibery counts as a verification. .next Individual routers can be explicitly skipped when running the routers to check an address given in the SMTP EXPN command (see the &%expn%& option). @@ -17225,7 +17241,8 @@ Setting this option has the effect of setting &%verify_sender%& and .cindex "EXPN" "with &%verify_only%&" .oindex "&%-bv%&" .cindex "router" "used only when verifying" -If this option is set, the router is used only when verifying an address or +If this option is set, the router is used only when verifying an address, +delivering in cutthrough mode or testing with the &%-bv%& option, not when actually doing a delivery, testing with the &%-bt%& option, or running the SMTP EXPN command. It can be further restricted to verifying only senders or recipients by means of @@ -17239,7 +17256,8 @@ user or group. .option verify_recipient routers&!? boolean true If this option is false, the router is skipped when verifying recipient -addresses +addresses, +delivering in cutthrough mode or testing recipient verification using &%-bv%&. See section &<>& for a list of the order in which preconditions are evaluated. @@ -27030,11 +27048,12 @@ is what is wanted for subsequent tests. .new .vitem &*control&~=&~cutthrough_delivery*& .cindex "&ACL;" "cutthrough routing" +.cindex "cutthrough" "requesting" This option requests delivery be attempted while the item is being received. It is usable in the RCPT ACL and valid only for single-recipient mails forwarded from one SMTP connection to another. If a recipient-verify callout connection is requested in the same ACL it is held open and used for the data, otherwise one is made -after the ACL completes. +after the ACL completes. Note that routers are used in verify mode. Should the ultimate destination system positively accept or reject the mail, a corresponding indication is given to the source system and nothing is queued. @@ -33496,6 +33515,7 @@ timestamp. The flags are: &`<=`& message arrival &`=>`& normal message delivery &`->`& additional address in same delivery +&`>>`& cutthrough message delivery &`*>`& delivery suppressed by &%-N%& &`**`& delivery failed; address bounced &`==`& delivery deferred; temporary problem @@ -33610,6 +33630,12 @@ flagged with &`->`& instead of &`=>`&. When two or more messages are delivered down a single SMTP connection, an asterisk follows the IP address in the log lines for the second and subsequent messages. +.cindex "delivery" "cutthrough; logging" +.cindex "cutthrough" "logging" +When delivery is done in cutthrough mode it is flagged with &`>>`& and the log +line precedes the reception line, since cutthrough waits for a possible +rejection from the destination in case it can reject the sourced item. + The generation of a reply message by a filter file gets logged as a &"delivery"& to the addressee, preceded by &">"&.