RE: [Exim] Autoreply using <> as sender - where mandated

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Paul Walsh
Datum:  
To: exim-users
Betreff: RE: [Exim] Autoreply using <> as sender - where mandated
On a similar note, it's a pity there isn't an RFC which states MTAs must
have forward and reverse DNS entries (or is there?)
I get rather irritated when more or less accused that our end is at fault or
broken because we bounce mail where the sending MTA doesn't have a reverse
entry or, less frequently, doesn't have a forward entry. I would've thought
it fair to say that any MTA worth its salt should have a coherent forward +
reverse entry in the DNS. What does the list think?

Paul Walsh

Senior Systems Programmer, Information Services,
University of Central England, BIRMINGHAM B42 2SU, UK
Tel: +44 (0)121 331 5708    Fax: +44 (0)121 356 2875


> -----Original Message-----
> From:    Philip Hazel [SMTP:ph10@???]
> Sent:    Monday, November 29, 1999 9:51 AM
> To:    Nigel Metheringham
> Cc:    exim-users@???
> Subject:    Re: [Exim] Autoreply using <> as sender - where mandated

>
> On Fri, 26 Nov 1999, Nigel Metheringham wrote:
>
> > It is accepted good practice for all autoreplies to have an empty
> > envelope sender to prevent loops - it is easy to make a case that this
> > is good practice.
> >
> > However are there any specifications (such as RFCs) around that mandate
> > or even suggest this? [I'd like a set of references in my armory for
> > hitting idiot mail admins with].
>
>
> RFC 2476                   Message Submission              December 1998

>
>    Note that a null return path, that is, MAIL FROM:<>, is permitted
>    and MUST be accepted. (MUAs need to generate null return-path
>    messages for a variety of reasons, including disposition
>    notifications.)

>
>
>
> -- 
> Philip Hazel            University of Cambridge Computing Service,
> ph10@???      Cambridge, England. Phone: +44 1223 334714.

>
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
> details at http://www.exim.org/ ##