On 06/15/2015 04:23 PM, Thomas De Schampheleire wrote:
On Mon, Jun 15, 2015 at 2:10 PM, Mads Kiilerich <[email protected]> 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 <[email protected]>
wrote:
Anyway, how about a first patch that refactors and consistently renames
"mail_from" to "envelope_from" (which seems to be the right technical
term
for what it is), and then another patch for setting "header_from" (or
reuse
mail_from).
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
filters
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
complex area:
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 [email protected]. 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.
/Mads
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
