[PATCH] notification: use Sender and From header to clarify comment and pull request mails
mads at kiilerich.com
Tue Jun 16 18:27:06 EDT 2015
On 06/15/2015 04:23 PM, Thomas De Schampheleire wrote:
> On Mon, Jun 15, 2015 at 2:10 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> On 06/14/2015 09:05 PM, Thomas De Schampheleire wrote:
>>> Hi Mads,
>>> On Fri, Jun 12, 2015 at 11:41 PM, Mads Kiilerich <mads at kiilerich.com>
>>>> Anyway, how about a first patch that refactors and consistently renames
>>>> "mail_from" to "envelope_from" (which seems to be the right technical
>>>> for what it is), and then another patch for setting "header_from" (or
>>> After further investigation, I don't think that 'envelope_from' is the
>>> right term. The envelope is something _around_ the message, the
>>> message being the contents _and_ the headers. These headers include
>>> both From: and Sender:
>>> There exist indeed the possibility of having an envelope sender, but
>>> this is not what we're dealing with here.
>> Ok. Then I guess the code & patch it could use some further clarification
>> for dummies ;-)
>> I haven't really digged into this since RFC 821 and 822 still applied, but I
>> guess it is essential
>> * that we still have a way to configure what sender is used when delivering
>> over SMTP (and thus where bounces will go)
> I don't understand what you're suggesting here...
>> * that we don't start setting sender in a way that interferes with the
>> normal delivery process
> I don't understand this either...
>> * that we don't make our mails more likely to be caught in spam prevention
>> A first safe step might be just change the "name" part of the from (and
>> sender?) headers based on who triggered the mail, without changing any
>> actual addresses.
> How do you know that this is 'safe' ? Are you sure that a spam filter
> may not be more suspicious by seeing the same e-mail address sending
> mail under different names?
It seems like we have some discrepancy in our understanding of how mail
works. Some brief statements, trying to outline how I see this big and
Mails are basically routed between Mail Transfer Agents routing/relaying
based on the envelope recipient and sender (pretty much independent of
the mail headers).
Mail relays have to be careful they don't forward spam (or bounce spam
to forged senders). One way to do that is to verify that the mail comes
from an IP address that the SPF protocol designates as valid for the
sender address. Kallithea thus have to make sure it doesn't use for
example a gmail.com as envelop sender address (unless the mails from
Kallithea actually are sent through a google server).
Mail User Agents will usually not see the envelope addresses (especially
because they often have been rewritten) but will only show MIME headers
like From, To, and perhaps Sender.
Spam filters are often a bit like IP routers/firewalls doing deep packet
inspection. They might look at anything using whatever heuristics works
for them (some also use well defined heuristics like DKIM headers).
"Forging" of headers is however quite common - see for example how this
mailing list works. Nothing can be guaranteed, but many valid uses
depends on this not being too strict.
See how bitbucket sends issue comments. It uses the users full name but
combines it with issues-reply at bitbucket.org. That makes me quite sure
the same thing would work for us.
Do you agree with some of the things I have said in this tread? Please
try to resend as a minimal change - perhaps with changes to the
documentation and .ini files explaining how it works with your change.
Then we can continue discussion based on that.
More information about the kallithea-general