On Tuesday, February 28, 2006 11:41 AM -0600, Stuart D. Gathman wrote:
Here is another thing that immediate rejection of invalid RCPT breaks.
DNSReport.com checks whether your MTA accepts mail to postmaster:
<...>
Arguably, they should not use MFROM <> for this test. However, they
do. A workaround could be to delay only postmaster and abuse
rejections
until after DATA.
The only problem is that you are arguably supposed to accept all mail to
postmaster and abuse. Though nobody who is awake would send it as null
sender, I don't recall an exception for that, even though it doesn't
make sense.
My real question is whether there is always a DATA command in a CBV?
While I've noticed there typically is one, is that always the case? For
example, isn't the following a usable CBV:
220 server.com
EHLO client.com
250 Welcome, client.com [192.168.50.3] ESMTP yada, yada, yada
MAIL FROM:<>
250 Accepted
RCPT TO:<postmaster(_at_)server(_dot_)com>
250 OK
RSET
250 RESET OK
QUIT
221 server.com closing connection
If it's possible that a CBV doesn't contain a DATA command, you
obviously can't delay rejection until after it. This would be an actual
problem if it were any other address besides postmaster or abuse.
Telling an MTA doing a CBV that an unsigned address is OK is telling
them to accept a forgery, and possibly send you backscatter if they
can't deliver it.
Since this was a CBV for postmaster, that should probably work even
though it starts out like a DSN, even though you would never receive a
DSN to _any_ unsigned address. This suggests the opposite logic: reject
after RCPT TO for any invalid address _except_ postmaster and abuse, but
delay rejecting for postmaster and abuse until after DATA, if at all.
As you've pointed out, there is zero chance of anyone brute force
guessing a signed return-path if the signature contains a long enough
random string, so relaxed dictionary attack countermeasures ought to be
satisfactory. This allows someone to validate that you accept mail to
postmaster without sending you any. Is that really necessary? Good
question. It doesn't really hurt anything, except for one of your
correspondent's brain-dead MTA's (see below).
Whether you should accept null sender mail to postmaster and abuse at
all is a separate issue. Sanity says no and RFC's imply yes. That's a
hard decision, so that makes it a local policy matter. Ever notice how
everything difficult becomes a local policy question?
I remember that you had a case where one of your customers corresponded
to a brain-dead MTA that did CBV's on your mail using a RFC822 address
instead of MAIL FROM. For some reason, rejecting after DATA caused
their CBV to pass, while rejecting after RCPT TO caused it to fail.
Well, it's already broken. Couldn't you just whitelist that bad boy and
assume other MTA's are run by sentient beings?
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com