Folks,
GC> My guess is that RFC2821 MAIL FROM will match From: or Sender: most of the
GC> time.
Certainly, for a very long time, folks thought RFC2822 Sender and
RFC2821 Mail From really were the same. They both were expected to list
the agent that initially injected the mail into the transfer service.
However that is not the world we live in today. RFC2822 is quite clear
about the intended semantics for Sender (cf, section 3.6.2). RFC2821
(section 3.3) has language that is proving somewhat more challenging,
since it refers to the "source" without explaining what that actually
means. However the second part of the language talks about actual use of
the string "to report errors", and actual use always trumps theory.
So, yes, frequently Mail From == Sender, such as for this very mailing
list.
However redirection of bounces to different addresses that are not
"source" addresses has become a common, essential requirement for many,
legitimate bulk mail operations.
GC> But, spammers/phishers are crafty- if MAIL FROM / Return-Path
GC> validation starts in earnest, they may start to diverge from this.
There is no "may" about it. Spammers use any means available to bypass
controls attempted against them.
GC> 4. Some checking of RFC 2821 HELO might be helpful but this should not be
GC> the main focus of the sender authentication effort.
Why?
What is it that we can be certain of learning from Mail From, versus
what is it we can be certain of learning from EHLO?
And why is one more important than the other, for control of spam.
GC> However, some users have reported that they get really great results
GC> from...
We need to be very, very careful about _any_ statement beginning with
language like this. There have been many "localized" effects in the
control of spam, but nothing has had any global effect at reducing spam.
Therefore, generalizing from prior experience in spam control can be
very misleading. Often, something that works in small, local
environments, does not scale to the global Internet.
How do people feel about coming up with a draft RFC that focuses on
RFC2821 MAIL FROM first and following up with a DATA/Headers extension
to it later? Can we have multiple draft RFC's come from the same working
group?
If the work is within the scope of the working group's charter, then it
is fine to have multiple specification documents
YS> The key here is whether the DNS-based mechanism that is defined in this
YS> WG will allow for both. If the mechanism is made extensible enough, than
YS> we can start off with the MAIL FROM or HELO mechanism first, get that
YS> approved, and then delve into the "from" header issues.
The question will be whether an "extension" to the first mechanism will
provide the requisite necessary functionality. FWIW, my guess is that
this "extension" will require a different mechanism, even if both use
the DNS.
AD> - MTA's are MTA's for one domain
not really. ISPs that support customer-specific domain names have MTAs
that service many domains.
AD> Now. As I said, back when RFC 821 was written, that kind of
AD> deployment was not widely used, so the RFC's weren't written with that
AD> configuration in mind.
(Not that this alters the technical discussion, but just to offer some
history...)
In fact off-net relaying was a core part of the discussions for RFC2821,
both with respect to the design of SMTP and the benefit of domain names.
There were at least two major relaying operations on the net at the
time, and one of them was particularly well represented in the SMTP
specification efforts.
This latter activity was called CSNet -- it turned out to be a precursor
to NSFNet -- and two sites did relaying for about 30-40 organizations,
in those days. So, udel.edu and rand.org were the domains listed in the
HELO string, but were typically not the MAIL FROM or From or Sender
strings.
What _has_ fundamentally changed, of course, is the implicit trust
through the service. sigh.
AD> What does it mean when an MTA delivers mail for many domains?
It means we need to be clear about the role of a third-party carriage
service. That's like postal monopolies (USPS, Canada Post, etc.) or
Fedex/UPS, or a telephone company.
As we consider having the carriage service impose requirements on the
content, we should pay careful attention to prior experience with that
in related, large-scale services.
MCL> Here's another valid use of spoofing (again, apologies to Dave):
MCL> Anonymous remailers. If the postcard contingent aren't viewed as
I think folks missed the reason I took exception to using the word spoof
to cover legitimate situations: Very simply, it is not spoofing.
Spoofing is about deception, typically by a third party. When the mail
says it is from me and, in fact, it is from me, then it is not spoofing.
The fact that I might be sending the mail from a different place than
usual does not make it spoofing.
When you are traveling and you post a letter with the hotel, rather than
by having the letter carrier pick it up from the mailbox attached to
your house, is that spoofing? Of course not.
It is mobility. It is flexible posting. It is posting from multiple
MUAs. It is lots of things. But it is not spoofing.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>