RE: [Asrg] Some data on the validity of MAIL FROM addresses

["Eric Dean" <[e-mail]>]

Lemme tell you, I would love to perform SMTP rejects instead of bounces.
The problem is that anyone with any non-trivial amount of email has to run a
multi-level SMTP architecture.

Often, you have an MX server that accepts email and performs some rejects
due to various RFC criteria...however, once you accept that message..you are
obligated to handle it now.  If you then forward to a spam-filter server,
then strictly speaking you should bounce the message rather than silently
discard..but to each his own.

If you are running Exchange or Notes, it's a non-trivial interface to the
namespace to determine if a user is local...those who use a database can
often have the MX server and Email Application Server (POP/SMTP/HTTP) share
the same tables and therefore reject dictionary attacks rather than bounce
to non-existant email address (and watch the queue grow).  Sure, you can run
an LDAP interface to an Email server but often the dictionary attack is less
load.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Jon
> Kyme
> Sent: Tuesday, May 20, 2003 8:35 AM
> To: Dave Crocker
> Cc: ASRG
> Subject: Re: [Asrg] Some data on the validity of MAIL FROM addresses
>
>
> >Folks, the email operations world has increasingly moved away from
> >real-time processing of SMTP data.
> >
>
> A colleague has just drawn my attention to the relevant part of rfc2505
> (BCP 30) - for completeness here it is:
>
> <quote>
> 1.5. Where to block spam, in SMTP, in RFC822 or in the UA
>
>    Our basic assumption is that refuse/accept is handled at the SMTP
>    layer and that an MTA that decides to refuse a message should do so
>    while still in the SMTP dialogue. First, this means that we do not
>    have to store a copy of a message we later decide to refuse and
>    second, our responsibility for that message is low or none - since we
>    have not yet read it in, we leave it to the sender to handle the
>    error.
>
> </quote>
>
> I apologise for not thinking to reference this in my initial reply to the
> point you raised.
>
>
>
>
>
>
>
>
>
>
> --
> _______________________________________________
> Asrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/asrg
>

_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg