ietf-smtp
[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis: Permitted and prohibited characters in addresses

2008-01-08 03:03:16

<sm(_at_)resistor(_dot_)net> wrote:
 
Quoting Section 3.6.2.:
   "This specification does not deal with the verification of return
    paths for use in delivery notifications.  Recent work, such as that
    on SPF [42] and DKIM [43] [44], has been done to provide ways to
    ascertain that an address is valid or belongs to the person who
    actually sent the message."

DKIM doesn't look at return paths, it's a kind of "signed timestamp"
(Received) from an SMTP POV.  DKIM might help to identify mails that
should be accepted.  By itself DKIM doesn't help to identify mails
that should be rejected.  SPF FAIL can do, but the deployment of FAIL
is not yet so overwhelming to decree victory, see <http://spf-all.com/>

I've no real problem with the statement you quoted, I'd only wish that
2821bis offers a better description of the underlying problem:  The
border MTA is the last place where "ordinary" mails can be rejected
without causing harm.  "Accept on probation" is a seriously bad idea
for "ordinary" mails.  "Extraordinary" cases include SPF PASS, where
"accept on probation" still works.

IOW folks accepting mails with unverified return paths are in trouble:
If they follow 2821bis 3.6.3 they send bounces to innocent bystanders,
that can get them blacklisted and/or their bounces are ignored (that's
bad for real problems).  If they ignore 2821bis 3.6.3 and drop "spam"
later they managed to create a black hole for false positives.  While
RFC 2821 and 2821bis are clear about the latter issue (MUST in 3.6.3),
2821bis could be clearer about the former problem, receivers have only
one chance to get it right, at their border.

"Conversely, if a message is rejected because it is found to contain
 hostile content (a decision that is outside the scope of an SMTP
 server as defined in this document), rejection ("bounce") messages
 SHOULD NOT be sent unless the receiving site is confident that those
 messages will be usefully delivered."

Yes, that's fine, when the identification of "hostile" is very near to
perfect - otherwise we'd be back in the "drop false positive" black
hole.  Extending the definition of "hostile" to various kinds of spam 
would reduce the identification rate, and create a conflict with the
MUST in 3.6.3.  We don't need to talk about the merits of 3.6.3 "as
indicated by the reverse-path" for mails identified as spam, but is
it really clear that accepting spam was an irrevocable *error* at the
border MTA ?

In practice, you can avoid the "drop the mail if it didn't work" by 
making that decision at the SMTP stage as far as possible.

It's not optional, between the lines it is REQUIRED, and there's only
one place for "ordinary" mail to get it right, at the border.  That's
clear for folks on this list, but is it also clear for other readers
of 2821bis ?   
 
In the original SMTP, 251 or 551 are used when destination 
information is incorrect and the SMTP server knows the correct 
destination.

Yes, that's the only case of "forwarding" discussed in RFC 821.  

This is different from 1123 5.3.6(a) which  talks about alias
expansion.  We have to keep the envelope sender as is unless we 
want to bring back source routing.

There's no problem with local aliases.  And an alias at a third
party is again forwarding, where keeping the return-path "as is"
was indirectly introduced by RFC 1123 5.3.6(a).  The old envelope
sender is not more reponsible for this transaction.  The user who
arranged it and the MTA deciding to try a "251" are responsible.

With RFC 821 reverse routes that was clear, but RFC 1123 5.3.6(a)
removed this responsibility from SMTP.  That was an "undesirable
side effect", IMO it created what's today known as spam problem.

If we are going to address the spam problem, we have to restrict
a lot of the mail functionality which 2821 offers.  We'll never
see 2821bis published if we start that discussion.

Of course 2821bis can't *solve* the spam problem, or reintroduce
reverse routes.  But it should be honest about critical points
in the post-821 design:  Border MTAs accepting dubious mails have
already screwed up badly, and forwarders thinking that "keep the
MAIL FROM 'as is'" was the original design missed that this was a
bug introduced later.

I'm also not sure about IPv6 MX and AAAA issues when an IPv6-
only sender meets an IPv4-only receiver with the help of an
IPvAnything forwarder, a variant of the 1123 5.3.6(a) issue.
 
The IPv6-only sender can relay the mail through a host that 
supports dual-stack operation.

What I had in mind was mail from an IPv6 only network forwarded
by a dual-stack forwarder to an IPv4 only network.  And at this
point addresses in the forwarded mail, especially any "as is"
MAIL FROM address, violate MUSTard in 2821bis:  The IPv4-only
network cannot report errors to the IPv6-only network.  The user
arranging this can't reply from his IPv4-only network, SNAFU.

For simpler (non-forwarding) scenarios we could find that either
sender, or receiver, or both did something they shouldn't do as
"IPvXOnly" network.  For the forwarding scenario we are back at
square one, keep MAIL FROM "as is" was a design flaw.

 Frank