Thu, Jun 17, 2004 at 14:43:53, a.flavell wrote about "Re: [Exim] AOL - SPF - and EXIM":
>> You can discard these messages
> That would be a serious step to take. Much more serious than overtly
> refusing mail, IMHO.
>> or put them on bigboard,
> Sounds like grounds for legal action against the postmaster. Of
> course, IANAL.
Well, but this is not Internet problem.
>> but you can't reject it.
> 7.7 says
7.7 of RFC 2821? I treat its text as less important because RFC1123
is standard (STD3), but RFC2821 isn't. Having standard which explicitly
prohibits comparation of IP address and $sender_helo_name, and RFC
(even "proposed standard"), which allows any policy, I prefer standard.
> It is a well-established principle that an SMTP server may refuse to
> accept mail for any operational or technical reason that makes sense
> to the site providing the server. However, cooperation among sites
> and installations makes the Internet possible. If sites take
> excessive advantage of the right to reject traffic, the ubiquity of
> email availability (one of the strengths of the Internet) will be
> threatened; considerable care should be taken and balance maintained
> if a site decides to be selective about the traffic it will accept
> and process.
These are good words but they must be adopted to a particularity. STD3
prohibits only one kind of rejection policy. It doesn't go on, and
the quoted paragraph cooperates with it.
> I don't see anything there which prohibits you from deciding to reject
> mail "for any operational or technical reason that makes sense to the
> site providing the server". It does no more than to ask for care and
> balance in the interests of the wider community.
> The argument has been exercised repeatedly here that 4.1.4 says:
> An SMTP server MAY verify that the domain name parameter in the EHLO
> command actually corresponds to the IP address of the client.
> However, the server MUST NOT refuse to accept a message for this
> reason if the verification fails:
> and some appear to claim that this forces you to accept a mail if the
> HELO verification fails, overruling any other clauses that would allow
> you to reject it. I don't buy that.
I also don't.
> Even if I'm told not to reject mail solely on the basis of the
> HELO/EHLO domain failing to verify, I'm sure I can find some other
> justifiable reason for rejecting such mail, and I reckon 7.7 confirms
> my right to do that, even within the scope of the RFC itself.
Of course.
And HELO verification isn't the most sharp question here. A host of ours
was filtered by another party due to the following reaction:
C: mail from:<>
S: 550 5.7.1 <a policy rejection reason>
and this was incorrectly treated as violation of RFC1123 par. 5.2.9, in spite
of fact that such policy rejection was applied to almost any sender.
(Compare withh aim of SPF.)
Another case was rejection of bounces to postmaster@our_domain, due to common
policy that no bounces should be accepted to mailing lists because it is
invalid (due to our policy) to send mail from mailing list address.
Unfortunately, this was treated as absense of postmaster account.
Pity but exim has standard possibility to check postmaster existence with
empty return address. We had to change rule for such combination from `reject'
to `discard', only for such invalid testers.
>> If you will reject them, you should be filtered.
> To adapt the wording of the RFC to modern conditions, I might say:
> Because sites have taken excessive advantage of the right to transmit
> traffic, the ubiquity of email availability (one of the strengths of
> the Internet) *is* threatened;
> We can't unilaterally change that deplorable state of affairs. We can
> only do our best to protect our users from the 'net (as well as to
> take responsible steps to protect tne 'net from our users, by the
> way).
Well, and who can really change the state?
I was told that IRTF ASRG is the main place and the authority to deal
with spam, sender fake and other problems of contemporary Internet.
But if they even can't filter their own mail archive from spam, we don't
have any real arm to change. (Don't say for AOL & Microsoft, they can't
by definition.)
-netch-
