Hi,
after having lots of discussion about spam and my
draft with people from around the world and after following
the asrg group for two days now, I believe to have identified
a major barrier in fighting spam. It's the ubiquituos
"I demand/need to send any mail with any sender address
from anywhere in the world."
But what's the background for this? When in the history
of e-mail did this arise and why?
The reason is simple: It's mainly the POP account.
People need to exchange e-mail from virtually anywhere,
whether from home with a dynamically allocated IP address,
of from any phone plug in a hotel right in the middle of nowhere,
with an IP address of any local ISP. That's OK, I agree with that.
I do it the same way.
But there's a harmful and irrational asymmetry in the mail path:
When receiving e-mail, people find it fully acceptable and just
normal and natural to
- have a central mail hub receiving their e-mail, operated by some
kind of ISP,
- that hub to have a fixed IP address and to be linked to their
domain/e-mail address through DNS
- that this mail hub is worldwide responsible and authorized
for their domain/e-mail address in context of e-mail reception
- to identify and authorize against that hub before downloading their
e-mail through POP.
That's fine and I never found anyone who seriously wanted to question
this.
But when sending e-mail, things dramatically change:
- Many ISPs deny to support their clients in mail delivery.
- Even if they do, most clients deny to use it.
- Instead, clients insist on directly deliver their email
to the world through SMTP without any authorization/authentication.
That's counterproductive and harmful, since there is no technical
difference between this and forged/unsolicited e-mail.
The obvious, self-evident, and reasonable way would be to use the
same path as for receiving e-mail, just in opposite order:
- the client doesn't send e-mail directly to the recipients MX
machine, but instead drops it to its mail hub after authentication.
(The mail hub might apply further services such as virus scanning.)
- The mail hub then delivers the mail to the world and is considered
to be responsible and authorized to deliver mail from that domain.
The hub still has a fixed IP address which is linked to the domain.
Would be a perfect symmetry. Deliver the same way and method as you
receive.
Surprise: That already exists. Many POP providers also offer the
service of delivering the mail. Authentication is possible through
either a so called "SMTP after POP" or a simple Password
authentication in the SMTP protocol, typically the same password as for
the POP account.
That's perfect, it does the job, and it's already implemented and
publicly available. And after all, it even works better for the client
than direct delivery, since the client doesn't need to cope with
unavailable DNS servers or other relays. And it is not even
a limitation, since the client depends on the presence of the
mail hub anyway. Life could be so easy and simple.
Unfortunately, too many ISPs and clients refuse to use it.
Therefore I suggest to declare as deprecated:
- ISPs who offer reception (POP) services without offering
delivery (SMTP) services.
If POP download is possible from a given IP address a.b.c.d,
then SMTP delivery must be possible as well with the same
set of authentication information, i.e. same username and password.
Message receiving through POP must be bundled with message delivery.
- Clients downloading e-mail through POP, but not using the
bundled delivery service. (That's btw poor client configuration.)
That's a quite simple demand. No need to develop new software. Most
software out there is already able to handle this, just needs to be
configured appropriate.
Once people follow this, the "I need so send e-mail from anywhere when
I'm on road" objection vanishes into thin air.
Once this happened, the door is open to implement a sending relay
authentication, maybe through RMX records or cryptographic certificates.
Hadmut
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg