Ok,
Because you decided that this trivial diff deserves a thread, I tried to find
the original diff and couldn't. I found it strange because I usually keep the
diffs even after they are applied due to bad ${HOME} keeping.
So I dig into the archives and read back the thread:
http://news.gmane.org/gmane.mail.opensmtpd.general/15
The diff you sent got rejected because it proposed to remove the Received line
plain and simple. You sent a diff adding two new knobs, one that we had strong
opposition with, the other because you just proposed adding a knob and we dont
do that just like that. You have to convince us why it is needed and why it is
something that has to be done at smtpd.conf level:
>
> I think something like this is actually best controlled by a nob.
>
You must have a MUCH MORE convincing argument to introduce knobs ;-)
This IS the exact same for me or eric or chl or anyone really. The reason why
smtpd.conf is simple is because we make it hard to add knobs to it unless the
discussion PROVES it is needed.
We could have discussed about it but the discussion somehow switched to filter
API and you made several assumptions which I told you were wrong because there
was work in progress that was done in a private repository. You made more, and
more, and more, and after I told you SEVERAL times to stop making assumptions,
I gave up and deleted the mails as they were a waste of time.
I'll leave it as an exercise to the reader to count how many times I told you
that you made invalid assumptions in the thread above. No wonder I forgot the
diff... I deleted the thread as I came to the conclusion it was clueless. You
can't convince me that a knob is valid when you keep making wrong assumptions
and ignoring me when I tell you they are wrong.
And now, your mail ends with what ?
Oh right, the *EXACT SAME ASSUMPTIONS* about the API and what it can and cant
do despite the fact you don't know what the final API is and despite the fact
I told you in the past that your assumptions were wrong:
>
> By the way, regarding a potential hide-received flag and whether or not to
> use the filter API for it -- these lines become hard to parse when they're
> multiple lines.
>
WRONG.
The API layer *may* expose a multi-line header as a single header to the
callback, it was discussed.
> But not only that -- it's not even passed to the filter API
> right now because it's appended directly to the file, so AFAIK, there's no
> way to filter it out. It just seems nicer to prevent it from being written
> at all, rather than have to monkey wrench it off with a filter.
>
WRONG.
The API layer will see EVERY line, including the one we prepend.
Yes, even if it doesn't do it now in the public repository.
I told you the EXACT SAME THING in the last thread.
I give up, I'm very patient but your quota in wasting my time is exceeded.
If you want to be taken seriously you need to STOP MAKING ASSUMPTIONS about
how you think things work. So far you had 0% success with your guesses.
As for the diff, I reimplemented a similar one, it happens.
Live with it.
--
Gilles Chehade
https://www.poolp.org @poolpOrg
--
You received this email because you are subscribed to the "[email protected]"
list
To unsubscribe, send mail with subject: [[email protected]] unregister
