--On 17 June 2009 01:14:02 -0400 Bill Cole <asrg3(_at_)billmail(_dot_)scconsult(_dot_)com>
wrote:
Franck Martin wrote, On 6/16/09 11:33 PM:
Knowing that mail servers are not deployed on IPv6, what would it take to
make all these requirements mandatory for IPv6 and start with a better
infrastructure than on IPv4?
How do you make anything mandatory on the net?
RFC 821 is one of a handful of Internet Standards, and it is violated
routinely by spammers and non-spammers for no better reason than that
they never bothered to read it.
Well, parts of it are. The rest is mandatory for the purely practical
reason that you can't deliver email without obeying those parts. For
example, to send email to someone, it IS mandatory to give their email
address in a RCPT command.
How do you make other parts mandatory? Well, it's a long and arduous task,
but the steps look like this:
1. make sure that the bulk of client MTA's behave correctly
2. start basing reputation scores on failure to respect the standard
this can take several forms: refusal to whitelist non-compliant
senders, incrementing spam scores, rejecting mail
As the deliverability of non-compliant email drops, the proportion of
senders complying will increase. A virtuous circle takes us to a world
where everybody is compliant. Eventually, even the spammers comply. So,
it's just an arms race in some cases, but in other cases we may have
regained some real value. For example, if respecting SPF were universal
(with fixes for forwarding), then backscatter would not be a problem.
That is possible because the major MTA's
are functional when misconfigured (e.g. with a bogus name for EHLO/HELO
use) and by default tolerate clients which violate standards.
The only way anything can be functionally mandatory for email transport
is if major MTA's will not work unless configured to comply and by
default will not interoperate with clients that do not comply. RFC's are
great, but they do not enforce themselves. If the big freemail providers
and sites running Sendmail, Exchange, and Postfix generally accept mail
from non-compliant clients, there will be a lot of non-compliant clients.
To make good behavior mandatory, bad behavior has to break with enough
frequency that it's easier to comply than negotiate exemptions.
----- Original Message ----- From: "Bill
Cole"<asrg3(_at_)billmail(_dot_)scconsult(_dot_)com> To: "Anti-Spam Research
Group -
IRTF"<asrg(_at_)irtf(_dot_)org> Sent: Tuesday, 16 June, 2009 8:27:27 PM GMT
+01:00
Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Asrg]
What are the IPs that sends mail for a domain?
Lyndon Nerenberg wrote, On 6/16/09 9:55 PM:
On Tue, 2009-06-16 at 17:24 -0700, Douglas Otis wrote:
IMHO, all outbound MTAs should be required to return CVS records for
their EHLO name and offer MX records for their inbound.
Doug, are you sure that's what you meant to say? The sentence is a bit
ambiguous. Are you really saying any host that sends mail (is an SMTP
client) MUST also host an listed SMTP server?
I can't testify to what he meant, but I think what he is actually saying
is that if you have a machine that says "EHLO some.name" then there
should be both a MX record for some.name and a SRV record for
_client._smtp.some.name (i.e. a CSV/CSA record).
That doesn't mean requiring inbound SMTP on every outbound, it means
requiring an affirmation in DNS that a name can be used in EHLO by a
particular IP address and a way to get mail to the responsible party for
the machine(s) using that name in EHLO. This is an admirable goal. A
weaker goal would be to get people running non-spamming mail servers to
follow the existing accepted standard of using a valid resolvable FQDN in
EHLO.
_______________________________________________ Asrg mailing list
Asrg(_at_)irtf(_dot_)org http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________ Asrg mailing list
Asrg(_at_)irtf(_dot_)org http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg