wayne at midwestcs
Feb 23, 2004, 1:06 PM
Post #7 of 10
In <20040223191503.GA3846 [at] uk> Brian Candler <B.Candler [at] pobox> writes:
> On Mon, Feb 23, 2004 at 01:03:48PM -0600, wayne wrote:
>> > I don't see how validating HELO can in any way confirm that a bounce is
>> > really a bounce, not spam.
>> Validating the HELO won't say if the bounce is spam or not, but then,
>> neither will checking the SPF record nor checking SRS.
> SRS will, if you accept bounces only to SRS-signed addresses.
No, SRS will not confirm that the bounce isn't spam. If you email a
spammer, the message you get back can be anything, inclucing spam. If
you publish or leak your SRS envelope-froms, a spammer can send spam
Validating the HELO domain, the SPF record or the SRS address do not,
in and of themselves, have anything to do with spam. The can,
however, make it harder for spammers to use invalid data to get you to
accept their spam.
> Can you give an example of how SPF prevents a spammer sending spam
> pretending to be a bounce?
SPF doesn't prevent spam, nor does it prevent non DSN from being sent
using a null MAIL FROM:. SPF helps prevent a domain name from being
>> RFC2821 is kind of muddled here. There is a
>> paragraph in section 4.1.4 says "However, the server MUST NOT refuse
>> to accept a message for this reason if the [domain/ip-address]
>> verification fails: [...]", however this appears to be talking about
>> rejecting at the HELO/EHLO command time
> it says "must not refuse to ACCEPT A MESSAGE" [i.e. at RCPT TO/DATA time],
> my emphasis.
Again, the MAIL FROM and RCPT TO commands allow you to reject mail for
"policy reasons". I see no reason why SPF checks based on many
things, including the HELO domain, are not valid "policy reasons".
SPF doesn't not reject a message just because the helo domain and the
client IP address don't match. These two don't even need to match in
order to pass SPF checks and SPF was developed in large part because
the IP addresses that are used to send mail are often not the same as
the A/MX records listed for the domain.
>> It is far easier to add a single line to a RHSBL to block an entire
>> domain (and their subdomains), than it is to track their constantly
>> changing IP address allocations.
> I say the opposite. It's much easier to block an ISP by their (very
> occasional) registry allocations, as opposed to the thousands of domains
> they may host, growing daily.
Sometimes it will be easier to squash spam via IP addresses, in which
case DNSBLs are great. There are many times which it is not so easy,
and SPF lets makes RHSBLs much more useful. I don't care how you
squash the bug as long as the bug gets squashed.
>> You snipped the two things in the domain registration that are very
>> hard to forge: the name servers for the domain and the registrar.
>> IANA says that the rest of the information must also be valid and
>> recently registrars have started to widely enforce this rule.
> So it will be better than the information ISPs hold about their
> really do doubt it. How are they enforcing it?
There are many free email providers out there that require almost no
information about you. The minimum amount of information needed to
register a domain is more than a very large number of ISPs.
As far as enforcement of registrar information, all you need to do is
complain to the registrar. If the registrar doesn't make sure the
information is validated, they can get in trouble with the IANA. This
enforcement is a fairly recent change, starting sometime last
summer/fall. I suspect that this enforcement will only get stronger
in the future. There is no equivalent requirement on
ISPs/companies/free-email providers enforcing valid information.
> The nameservers are public information in the DNS, and since the NS records
The name servers in the whois data is different than the name servers
in the DNS information. The whois NS info is easier to track and control.
The whois NS info can also be easily taken over by the registrar and
locked so that the domain owner can't change it.
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss [at] v2