39 ms·

I've created two email startups (https://ohmysmtp.com https://ohmysmtp.com and https://idbloc.co https://idbloc.co) - email is hard, thanks in no small part to

I've created two email startups (https://ohmysmtp.com https://ohmysmtp.com and https://idbloc.co https://idbloc.co) - email is hard, thanks in no small part to these issues which are basically undocumented or at least not specified. To avoid this, the Hanami team could add a reply-to header that routes back to the original sender, update the from header to come from them (to pass DKIM and SPF), and instead of forwarding on directly, re-build the email and resend it as a fresh, DKIM signed-one. This is how we do it at IdBloc (we add the via bit): from: Original Sender via IdBloc.co <sender-at-domain.com@users.idbloc.co> reply-to: "Original Sender" <sender@domain.com> If they want to act as a complete firewall in between, they can change the reply-to address as well and completely rebuild the email each time.

supermatt 6y ago
These "issues" are EXTREMELY well documented AND specified. To be fair, we don't actually know the authors intent (and I would argue that they dont either). They should be either forwarding the signature (in the case of relaying) or signing with the senders domain key. They are instead signing with the relay domain key, which is all but useless.
- albertgoeswoof 6y ago
  Re. docs - not really, the "via" prefix is not documented in any RFC, it's Google who are ad-hoc defining this and making up a new standard.
  - deleted 6y ago
    [deleted]
  - RIMR 6y ago
    They haven't made up a new standard. The standard already exists. The "via" is just a way of visualizing this standard. Just because the "via" UI element doesn't appear in any RFC doesn't mean it doesn't represent something that does appear in an RFC.
    - albertgoeswoof 6y ago
      It needs to say something like Reply To MUST match From, if not the email client MUST display a visual representation I don't see that kind of thing in an RFC anywhere though?
      - Ayesh 6y ago
        I think the "problem" shown in this article is when Gmail shows the "via" text when the From domain is different to the signature header. It's very common to have From addresses different to Reply To; a contact form for example should do this.
      - supermatt 6y ago
        DMARC RFC says something along those lines (Identifier Alignment). With DKIM anyone can sign the email, its up to the verifier to decide who to trust and how to represent that. DMARC formalises who you should trust (i.e. the domain key for the sender). p.s. It seems you can click on the "via" in gmail and it gives you some (rubbish and borderline misleading) information.
- SavantIdiot 6y ago
  @supermatt you really get this stuff. Is there an OReilly (or other) book you'd recommend, or is all this knowledge part of the vast, distributed online corpus of IETF RFCs and StackOverflow questions?
  - KronisLV 6y ago
    Agreed, any links (or references to books) about the subject matter would be helpful! At this point i feel like a lot of e-mail related topics are full of "unknown unknowns" to me and many other developers. It's hard to say whether we're missing bits of information that are considered common knowledge or maybe e-mail related development doesn't have enough discoverability (like blog posts, tutorials and so on) to make it easier, like configuring HTTPS in Apache2/httpd would have. Or maybe the whole domain is just full of inherent complexity due to its history (SPF, DKIM, DMARC etc.).
    - supermatt 6y ago
      SPF, DKIM and DMARC arent really that complex. > SPF Is the relay authorised for this domain > DKIM Which domain(s) authored/approved this email > DMARC Formalises some behaviours for the above + reporting Much of this is to prevent a bad actor sending out emails from a domain they do not control (i.e. prevent spoofing). The REAL problems with email come with deliverability. Basically an MTA not forwarding or accepting mail from you. This can be for a variety of reasons: you are misconfigured, they are misconfigured, one of your relays is on a blocklist, your relay exceeds a rate limit, your emails exceed some spam score, etc. This is the stuff that makes service management painful. For example, gmail may give you a few "spam points" for sending them more email than they are used to from your relay - this means your emails end up in spam, get bounced and requeued for delivery (if you are configured correctly!), outright refused, or even mysteriously blackholed. It takes time to build reputation in that respect. Emails may be marked as spam by recipients, which can further tarnish your relays reputation with that provider (potentially multiple if they share reports with other providers). Using an IP with a history of abuse, or having bad neighbours on your subnet, or having emails flagged with a spam reporting service can result in you being added to blocklists - requiring you to be vigilant in log monitoring, postmaster duties, etc. Email isnt difficult, its just that bad actors have meant that you need to establish a positive reputation, rather than simply avoiding a bad one if you want to send any realistic volume of email to a large provider. DMARC/SPF/DKIM are intended to give accoutability in order to establish domain-based, rather than relay-based reputation - but ultimately its up to the receiving provider (and occasionally 3rd party relays, depending on your setup) how they handle it.
kureikain 6y ago
Thank you. I'm thinking about it as well but many other email forwarding service forward it as it's. so when I do different, they kind of confused. Plus, many mail client show the from as well. So it confused user quite a bit.
- albertgoeswoof 6y ago
  Agree, it's not really email "forwarding" if you parse the email then resend it. Then again what is email forwarding anyway, it's all such a mishmash

supermatt 6y ago

These "issues" are EXTREMELY well documented AND specified. To be fair, we don't actually know the authors intent (and I would argue that they dont either). They should be either forwarding the signature (in the case of relaying) or signing with the senders domain key. They are instead signing with the relay domain key, which is all but useless.

albertgoeswoof 6y ago
Re. docs - not really, the "via" prefix is not documented in any RFC, it's Google who are ad-hoc defining this and making up a new standard.
- deleted 6y ago
  [deleted]
- RIMR 6y ago
  They haven't made up a new standard. The standard already exists. The "via" is just a way of visualizing this standard. Just because the "via" UI element doesn't appear in any RFC doesn't mean it doesn't represent something that does appear in an RFC.
  - albertgoeswoof 6y ago
    It needs to say something like Reply To MUST match From, if not the email client MUST display a visual representation I don't see that kind of thing in an RFC anywhere though?
    - Ayesh 6y ago
      I think the "problem" shown in this article is when Gmail shows the "via" text when the From domain is different to the signature header. It's very common to have From addresses different to Reply To; a contact form for example should do this.
    - supermatt 6y ago
      DMARC RFC says something along those lines (Identifier Alignment). With DKIM anyone can sign the email, its up to the verifier to decide who to trust and how to represent that. DMARC formalises who you should trust (i.e. the domain key for the sender). p.s. It seems you can click on the "via" in gmail and it gives you some (rubbish and borderline misleading) information.
SavantIdiot 6y ago
@supermatt you really get this stuff. Is there an OReilly (or other) book you'd recommend, or is all this knowledge part of the vast, distributed online corpus of IETF RFCs and StackOverflow questions?
- KronisLV 6y ago
  Agreed, any links (or references to books) about the subject matter would be helpful! At this point i feel like a lot of e-mail related topics are full of "unknown unknowns" to me and many other developers. It's hard to say whether we're missing bits of information that are considered common knowledge or maybe e-mail related development doesn't have enough discoverability (like blog posts, tutorials and so on) to make it easier, like configuring HTTPS in Apache2/httpd would have. Or maybe the whole domain is just full of inherent complexity due to its history (SPF, DKIM, DMARC etc.).
  - supermatt 6y ago
    SPF, DKIM and DMARC arent really that complex. > SPF Is the relay authorised for this domain > DKIM Which domain(s) authored/approved this email > DMARC Formalises some behaviours for the above + reporting Much of this is to prevent a bad actor sending out emails from a domain they do not control (i.e. prevent spoofing). The REAL problems with email come with deliverability. Basically an MTA not forwarding or accepting mail from you. This can be for a variety of reasons: you are misconfigured, they are misconfigured, one of your relays is on a blocklist, your relay exceeds a rate limit, your emails exceed some spam score, etc. This is the stuff that makes service management painful. For example, gmail may give you a few "spam points" for sending them more email than they are used to from your relay - this means your emails end up in spam, get bounced and requeued for delivery (if you are configured correctly!), outright refused, or even mysteriously blackholed. It takes time to build reputation in that respect. Emails may be marked as spam by recipients, which can further tarnish your relays reputation with that provider (potentially multiple if they share reports with other providers). Using an IP with a history of abuse, or having bad neighbours on your subnet, or having emails flagged with a spam reporting service can result in you being added to blocklists - requiring you to be vigilant in log monitoring, postmaster duties, etc. Email isnt difficult, its just that bad actors have meant that you need to establish a positive reputation, rather than simply avoiding a bad one if you want to send any realistic volume of email to a large provider. DMARC/SPF/DKIM are intended to give accoutability in order to establish domain-based, rather than relay-based reputation - but ultimately its up to the receiving provider (and occasionally 3rd party relays, depending on your setup) how they handle it.

kureikain 6y ago

Thank you. I'm thinking about it as well but many other email forwarding service forward it as it's. so when I do different, they kind of confused. Plus, many mail client show the from as well. So it confused user quite a bit.

albertgoeswoof 6y ago
Agree, it's not really email "forwarding" if you parse the email then resend it. Then again what is email forwarding anyway, it's all such a mishmash