>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.
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.]
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?
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.
[...] 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.]