On Mon, 2004-05-10 at 07:48, Tony Finch wrote:
On Sun, 9 May 2004, william(at)elan.net wrote:
Authentication with submit should be preferred option. In fact it should
be done no matter if its remote user or not. Changing behavior in this way
will go long way towards fighting spam.
I see bad disadvantage to adaption of above for roaming is that some
roaming networks proxy all SMTP connections to their own servers and then
AUTH would fail.
I don't think it is usual to do this for SUBMIT.
We should write something up that says that during client
email submit if SMTP AUTH is chosen as preferred option but fails, the
client email system should try sending email without AUTH (rather then
immediatly give failure notice). In that case if smtp is being proxied
and SMTP AUTH to home server fails it may still work going through this
proxy in normal way.
IME this case is a recipe for messages disappearing without a trace. For
example, Freeserve's transparent SMTP proxies are in the MAPS DUL so when
my users try to send email at home they often find that our servers reject
both the original message and the resulting bounce. Similar effects will
result from LMAP or SES rejections.
Many cable modem and DSL providers implementing dynamic addressing also
prohibit their customers from acting as a server. Here is an excerpt
from a Comcast High-Speed Internet Acceptable Use Policy "Prohibited
Uses and Activities"-
http://www.comcast.net/terms/use.jsp
"(xiv) run programs, equipment, or servers from the Premises that
provide network content or any other services to anyone outside of
your Premises LAN (Local Area Network), also commonly referred to as
public services or servers."
Disabling systems likely running a Trojan sending mail to SMTP
recipients not belonging to the ISP is the function of a Dial-Up List
(dynamic IP range list). Many public access networks are engineered to
offer asymmetrical connectivity for typical use. Serving information at
the access point overwhelm up links and hence the need for this
prohibition. Trojans acting as servers already account for half the
network traffic.
With this said, rather than using the IP address to identify the MTA
which is a blunt instrument, it would be safer to use the helo/ehlo
domain published in DNS instead. Such a practice could prohibit a
connection early in a manner similar to DUL/RBL list use. This
helo/ehlo domain could remain relatively static and need not be related
to the domain of the message 'from' information and thus easier to
manage. Envision a domain with a good reputation offering use of their
domain for this purpose.
Having fewer domains being authorized to handle mail on behalf of other
domains will simplify other schemes taking years to put into practice.
Is there an major reason why SPF can not use the helo/ehlo domain as a
primary reference rather than as a fall-back? The SPF proposal should
consider an immediate benefit of using DNS to authorize the MTA long
before repudiating mail 'from' becomes practical. From my
understanding, the first task of this work group is to consider
authorizing the MTA and not repudiating mail 'from'. A consistent
method of authorizing the MTA will provide significant relief and can
serve as a foundation for mail 'from' repudiation. Consider MTA
authorization as a first step as indicated in the charter.
-Doug