Perhaps a better alternative to deprecating <> would be saying that MTAs
SHOULD bitbucket DSNs about email they know (thanks to LMTP and/or
Received/MessageID headers) weren't sent from authorized IPs/systems.
Good/workable idea?
On 11/29/2003 5:32 PM, Bill Cole sent forth electrons to convey:
At 11:41 AM -0800 11/29/03, Matthew Elvey wrote:
... IMO, MAIL FROM: <> needs to be deprecated in favor of refusal
during SMTP.
The null sender for system-generated messages about system-level
issues should NOT be deprecated without providing some solution for
everything that it is currently useful for. Bounces are just one
variation on the broader theme of DSN's.
True. By deprecated, I mean a spec that says that MTAs SHOULD not (not
MUST not) use <>. Let's see if there is another solution for
everything legit that it's currently useful for. We don't want <> to be
a way around LMTP, right? For any failure DSN, I think the systems
that send them can and should be modified so that all the failure status
codes of rfc 1893 can be provided during SMTP. Any intermediate system
(offline UUCP excepted) that does so would need to be redesigned, as you
point out below, if they wanted to avoid using <>. For any success
DSNs, perhaps they shouldn't be sent MAIL FROM: <>. Locally generated
and delivered mail shouldn't be bitbucketed.
There is no compelling reason to delay the mail validation process.
Whether that is true really depends on how narrowly you want to view
the email world. If you want to ordain that all mailable domains must
have the full knowledge of their namespace in every host that they
have an MX record pointing at, this is a very tall order for changes
from how a significant fraction of the net works today.
It provides no benefit that cannot be met with immediate
validation, barring the super-secure bastion host scenario Bill Cole
mentions, which could be resolved with some work. (I should admit - I
don't do what I preach, as the provider I choose to have host my
domain does accept spam that I'd prefer it refuse during SMTP, but I
have pushed them to fix the problem, and they do refuse a good
fraction of the spam during SMTP.)
That example was ONE case.
Thanks for providing more for discussion.
Without delaying the validation of the target address, every domain in
which there are mail addresses would need published MX records
pointing to machines with live access to the authoritative knowledge
store for each domain it serves. We could kiss UUCP goodbye finally,
and if you think no one still uses it you are quite wrong.
Valid point. (except we're deprecating, not forbidding)
Large organizations that now have single external faces on their mail
systems for many possible subdomains which actually route internally
in complex ways would need to be redesigned. As an example of this, I
work with a major systems vendor with a global workforce whose
individual email addresses reflect their geographic location, yet the
exterior MX record set for all of the subdomains is one server farm.
That server farm has to know how to route mail to many different
subdomains handled on many different machines around the world. It
DOES NOT have access to the full user namespace for all of those
domains, it merely knows that it accepts mail for the various
subdomains and hands it off internally to machines closer to the HR
departments for the various branches. Even without exposed subdomains,
such situations are problematic because companies beyond a certain
size simply do not operate as single entities and cannot operate their
email systems on single giant machines that know everything
simultaneously.
An intermediate system has 10 minutes after the end-of-data indicator to
contact the downstream system and find out if it will accept the
message; it could be redesigned to do so before sending the final 250
OK. Do you think the idea in the first line of this email is more
workable?
The fact of an address no longer being valid can easily take a day to
propagate throughout a global operation, and it is a rare large
company that can make the event of a user add or delete look
instantaneous to their entire email system.
I forget whether SpamAssassin supports what we're currently calling
CallerID Verification. It has NO_DNS_FOR_FROM: Domain in From header
has no MX or A DNS records, but I think it doesn't have the full
CallerID Verification.
I admit to having only skimmed the stuff on 'CallerID' because it
looks like the same unscaleable stuff that has been in in some MTA's
for a while with essentially tries a RCPT verification of every MAIL
FROM given, and there are probably enough of us managing mail servers
who will address that sort of behavior as just another attack (null
route the offending machine) so that the inherent scaling and indirect
attack problems don't ever make it to visibility.
It would rarely look like an (address harvesting) attack, I think.
Hector still has to address someone (?Yakov's?) point that he
isn't/can't provide accurate false positive data if he's rejecting mail
after MAIL FROM!
Hector? Until then, it's only a useful tool for a scoring system.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg