On Tue, 2004-07-27 at 18:26, Andrew Newton wrote:
On Jul 27, 2004, at 9:05 PM, Douglas Otis wrote:
This jump to step 5 omits checks for From headers in the message.
Right. My eyes missed the Resent-From. Sorry.
The random-1(_at_)dup(_dot_)com could have been a local user, (it had the
domain), but when relayed to a MTA with a list of valid users, the mail
was rejected as the local part 'random-1' was not valid. The MTA
to last in the chain, then bounces the message. This may allow
filtering, or if done by a backup MTA, the knowledgeable server is
expected to be out of service.
Why would the first MTA receiving for dup.com not just reject the
It could if the MTA either had a valid list of users, or attempted to
deliver down stream to ascertain if the user was valid before completing
the session. The MTA only knows it will relay for a domain. In the
case of the backup MTA service, this 'knowledgeable' server is expected
to be down. As a shortcut for administration or out of reluctance,
lists of valid users may not be shared with some MTAs relying messages.
These become a boon for those looking for a back door. This also
becomes a valid reason for sticking with the ASRG ground work and
dropping PRA. Contrary to moving away from the channel, the opposite is
needed. There are several _really_ good methods for strongly ensuring
the author when needed. Much better than the PRA stuff. In addition,
PRA can never protect the network. Abating abuse should be the goal and
not filtering where there will be a loss of integrity by design.