Hello.

I am still writing my DKIM signer (or, actually, for over six
weeks, i got distracted and ran away due to header remove code,
and realization that all RFCs written after Y2K seem to introduce
their own syntax rules instead of simply going for *822 or 2045,
etc etc etc; including DKIM :().

Whatever, now back at this i have problems with the milter
CHGHEADER command.  Even though

  git show \
    origin/main:contrib/sendmail/libmilter/docs/smfi_chgheader.html |
  lynx -stdin

in the FreeBSD source code gives

     * For smfi_chgheader, filter order is important. Later
       filters will see the header changes made by earlier ones.

i seems i cannot remove headers in the sequence 1,2,3 etc, as it
seems (working thesis, i did not look) to have been implemented as
a stack, and setting the lenght of a header to 0 (== removing it)
shifts stack so that a former 3 becomes 2.
Is that correct?

I think this is really strange, as any further filter will be
completely lost when it will try to remove headers, as possibly
any number has become obsolete, without any chance for recovery?

I implemented it like this because i thought that the only sane
way in a possibly lengthy filter queue is to keep any instance
"alive" (though length 0) until all the queue is worked.

I will now sit down and reimplement to perform removals top down,
but hoping i have done anything else wrong!

In the meantime i myself have dropped my SPF record (and still
thinking ~all is a totally useless thing), as i am now confident
in my own signer; i think only the library exim uses does it truly
right and standard-conforming, after having looked around into
quite some DKIM implementations, btw.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to