4 ms·

All mail systems have different rules for what is "acceptable", what is perceived as "spam", etc. One mail server may allow attachments up to 10MB, another 20M

by aethr 15y ago

All mail systems have different rules for what is "acceptable", what is perceived as "spam", etc. One mail server may allow attachments up to 10MB, another 20MB. Some mail server somewhere may allow attachments up to 50MB but will not allow attachments with a .exe extension, and due to the vast and wide uses of email it actually is important for this flexibility to be available. Given the amount of variablility around mail handling, relays, spam filtering, etc, I'm not sure that it's entirely feasible to "standardise" error or bounceback messages. RFC 3464-style messages get us part way there but it just doesn't approach something as "nice" as HTTP error codes (which themselves still aren't handled in a standard way by web browsers, they are handled on a case by case basis, if at all, by web developers). I think this problem is only going to approach being solved when some of the more edge-case uses of email (such as attaching/sending files) are deprecated by more targeted, more efficient services. For example, lets say everyone started using Dropbox or YouSendIt to send files instead of attaching them in emails. And alongside that perhaps a separate protocol such as iCal or similar takes over the "meeting arrangement" space. Eventually the usefulness of email may be narrowed down into a small enough band of "send and forget" messaging that someone can actually, finally, come up with a better, more efficient and usable alternative. Until that happens, or something else equally radical, email is something we're just stuck with, worts and all.

pbhjpbhj 15y ago
>One mail server may allow attachments up to 10MB, another 20MB [...] not allow attachments with a .exe extension, [...] important for this flexibility to be available. [...] I'm not sure that it's entirely feasible to "standardise" error or bounceback messages. // Well couldn't we use something akin to SPF - ie a TXT field in the domain's DNS record with a shorthand for the acceptable receiving protocol in operation, kind of an RPF. So you'd have something like: alicious.com TXT v=rpf1 deny-ext:exe,reg,dll max-size:15MB req-field:sender ip4:xxx.xxx.xxx.xxx/16 req-format:txtonly req-other:spf ... would tell the MTA (or the forwarding relay) that this address will likely reject emails containing exe, .reg, .dll files; emails over 15MB; emails without a sender field; emails apparently originating from servers outside the given address range; emails not in text format; emails from domains without a SPF; ... Whoops got carried away there. What would be the problems with this sort of scheme? [FWIW there's already a milter called RPF but that's not what I'm proposing here I'm talking instead about a policy to give to a sender to tell the sender what you intend to accept so that they can choose to match your requirements and avoid having the mail rejected. Obviously an MTA/MUA can choose to receive mail that doesn't adhere to the policy if they wish.]
- aethr 15y ago
  From a technical standpoint something like that could work to a limited extent (enough to be helpful in some situations, when both parties are using modern, up to date MTAs / mail clients). It still doesn't fix the error message from a bounce, it's more like a hint to the email author to say "this email might not be accepted for the following reasons: x, y and z". Ultimately though, the inertia to implement such a thing on existing MTAs is somewhere close to the difficulty of implementing IPv6. Except the need for IPv6 is verging on dire, and not many people seem to be rushing to fix that one. How will we convince people to act with any expediency over something that is, at most, an inconvenience?
  - pyre 15y ago
    > Except the need for IPv6 is verging on dire But we just got all of Iran's blocks back because they are removing themselves from the Internet, right?
  - pbhjpbhj 15y ago
    The MUA would do the work up front, query the TXT field for the rpf and tell yiu up front "I can't do that, $user wont accept attachments over 15MB". Then as the OP suggested the MUA can offer to zip, upload and link, or whatever.

by aethr 15y ago

pbhjpbhj 15y ago

>One mail server may allow attachments up to 10MB, another 20MB [...] not allow attachments with a .exe extension, [...] important for this flexibility to be available. [...] I'm not sure that it's entirely feasible to "standardise" error or bounceback messages. // Well couldn't we use something akin to SPF - ie a TXT field in the domain's DNS record with a shorthand for the acceptable receiving protocol in operation, kind of an RPF. So you'd have something like: alicious.com TXT v=rpf1 deny-ext:exe,reg,dll max-size:15MB req-field:sender ip4:xxx.xxx.xxx.xxx/16 req-format:txtonly req-other:spf ... would tell the MTA (or the forwarding relay) that this address will likely reject emails containing exe, .reg, .dll files; emails over 15MB; emails without a sender field; emails apparently originating from servers outside the given address range; emails not in text format; emails from domains without a SPF; ... Whoops got carried away there. What would be the problems with this sort of scheme? [FWIW there's already a milter called RPF but that's not what I'm proposing here I'm talking instead about a policy to give to a sender to tell the sender what you intend to accept so that they can choose to match your requirements and avoid having the mail rejected. Obviously an MTA/MUA can choose to receive mail that doesn't adhere to the policy if they wish.]

aethr 15y ago
From a technical standpoint something like that could work to a limited extent (enough to be helpful in some situations, when both parties are using modern, up to date MTAs / mail clients). It still doesn't fix the error message from a bounce, it's more like a hint to the email author to say "this email might not be accepted for the following reasons: x, y and z". Ultimately though, the inertia to implement such a thing on existing MTAs is somewhere close to the difficulty of implementing IPv6. Except the need for IPv6 is verging on dire, and not many people seem to be rushing to fix that one. How will we convince people to act with any expediency over something that is, at most, an inconvenience?
- pyre 15y ago
  > Except the need for IPv6 is verging on dire But we just got all of Iran's blocks back because they are removing themselves from the Internet, right?
- pbhjpbhj 15y ago
  The MUA would do the work up front, query the TXT field for the rpf and tell yiu up front "I can't do that, $user wont accept attachments over 15MB". Then as the OP suggested the MUA can offer to zip, upload and link, or whatever.