Re: [Asrg] What are the IPs that sends mail for a domain?

Ian Eiloart <iane@sussex.ac.uk> Wed, 17 June 2009 10:45 UTC

Return-Path: <iane@sussex.ac.uk>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791DA3A6E2F for <asrg@core3.amsl.com>; Wed, 17 Jun 2009 03:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9KLgTP3OImO for <asrg@core3.amsl.com>; Wed, 17 Jun 2009 03:45:31 -0700 (PDT)
Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id 196783A6E2C for <asrg@irtf.org>; Wed, 17 Jun 2009 03:45:31 -0700 (PDT)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:61163) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KLDPOA-0002DT-EP for asrg@irtf.org; Wed, 17 Jun 2009 11:40:58 +0100
Date: Wed, 17 Jun 2009 11:40:06 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: asrg@irtf.org
Message-ID: <4F1048B2056979F365961B93@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <4A387B9A.2040800@billmail.scconsult.com>
References: <10153223.1951245209543218.JavaMail.franck@somehost-55.sv2.equinix.net> <4A387B9A.2040800@billmail.scconsult.com>
Originator-Info: login-token=Mulberry:01MGpul5nL3Pxx18L5nJCj3+EKluKP8ZOQpdU=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 10:45:32 -0000

--On 17 June 2009 01:14:02 -0400 Bill Cole <asrg3@billmail.scconsult.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@billmail.scconsult.com> To: "Anti-Spam Research Group -
>> IRTF"<asrg@irtf.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@irtf.org http://www.irtf.org/mailman/listinfo/asrg
>> _______________________________________________ Asrg mailing list
>> Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg
>
> _______________________________________________
> Asrg mailing list
> Asrg@irtf.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/