Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
[Greg Connor <gconnor(_at_)nekodojo(_dot_)org> wrote:]
I would like to see the first push aimed at RFC2821 MAIL FROM,
Why? What does a validated bounces address tell you and what does it
take to validate it reasonably?
This deserves a real answer.
First of all, it tells you (the eMail admin receiving) that you can
safely pass this email on with assurance that a bounce message generated
after the close of the SMTP session is likely to reach someone who can
act on it. Otherwise, you'd need to do everything possible _during_ the
SMTP session -- since bouncing to an innocent third party (forged by a
spammer) is a BAD thing.
IMHO, validating a bounces-to address should rest upon a record
maintained by the eMail admin for the domain part, stating that this
particular SMTP sender (by IP address) is presumed to do appropriate
checking of the MAIL-From addresses it sends.
Note that "appropriate checking" covers a vast territory. For example,
a sending MTA could substitute a role account with an authenticated
sender enclosed in parentheses; or it could place the authenticated
sender directly following the MAIL-From; or it could (especially for a
personal domain) trust whatever the authenticated sender asks it to
put there.
(Some eMail admins will no doubt want to authorize different SMTP
senders for different users -- I hope we will leave expansion room to
handle this in the future.)
(Other eMail admins will no doubt want to override the bounces-to
address, perhaps retaining the original in parentheses -- I hope we
will leave expansion room for that, too.)
(Yes, I understand that unauthorized use of bounces addresses are a
problem, but the question is whether directly solving that makes sense
or whether solving it indirectly makes sense. Of course, the answer
hinges on the difficulty of each approach.)
IMHO, it's going to be hard enough to convince people to use a
"direct" solution. I'd avoid "indirect" solutions unless the "direct"
solutions don't actually solve it.
but beyond that, HELO checking might have some value too.
HELO asserts the identity of the MTA. It is the only place this is
asserted. Would it be useful to know that an MTA is authorized to be
an MTA?
This doesn't deserve a real answer; but I'll hint at one.
That it is authorized to "be an MTA" helps us not at all, unless the
authorization comes from a source we have reason to trust.
[Mark C. Langston <mark(_at_)bitshift(_dot_)org> wrote:]
" ... anecdotal data from the organizations for which I've worked
" over the past 15 years or so would indicate that the volume is
" somewhat higher than "a few geeks".
Indeed, the growth of hotspots and probably explosion of mobile
Internet access suggests that we be very careful in limiting access
and usage scenarios.
Here's where "authorized to be _an_ MTA" could help.
If such authorization was from a "trustworthy" source, and included
directions on overriding the bounces-to, we could indeed proceed to
trust the bounces-to and pass the email on to the next stage.
--
John Leslie <john(_at_)jlc(_dot_)net>