headers
Charles Lindsey | 1 Apr 12:45
Picon
Picon

Re: Message with no From at all (6)


In <IE23xw.FCn <at> clerew.man.ac.uk> "Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:

>So we have so far established that "From: <>" gets through to most people
>(except Bruce, who claims he never received his) but we need more evidence
>as to what systems allow completely absent Froms to pass through
>unscathed.

So, having failed to get my test messages (other than From: <>) through
the mail expander at imc, I sent test messages with no From header at all
directly to 12 people on this list who had replied to my earlier <> tests.

I have 9 replies, of which 6 reported that their local Delivery agent, or
an MTA close to that, had manufactured a From header out of the envelope
from (which was readily identifiable, being
postmaster <at> clerew.man.ac.uk). Two of these were Sendmail, two were
Postfix, and one was PMDF/JESMS (the other didn't say). It was reported
that Exim, Gmail and Qmail were happy to pass the message without
alteration.

Although Sendmail can be configured not to make this change, it is the
default and few sites change it (though one recipient had done so on his
own system). There was quite some discussion amongst some of these 12
recipients afterwards in which some of them expressed the opinion that the
current behaviour of Sendmail et al was actually a Good Thing, especially
for large ISPs. It was also reported that some IMAPs might not take kindly
to a missing From, although apparently Cyrus is OK.

So it looks like maybe 50% of existing systems would do unsuitable things
with Bruce's proposal, either by giving away the envelope From address
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Lilly | 7 Apr 18:52
Picon

Re: I-D ACTION:draft-arun-ncc-smtp-02.txt

On Tue April 5 2005 15:30, Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Ncc in Mail Header
> 	Author(s)	: A. Sankar
> 	Filename	: draft-arun-ncc-smtp-02.txt
> 	Pages		: 4
> 	Date		: 2005-4-5
> 	
> This draft presents a mechanism to simplify one of the cumbersome 
> aspects of mailing, when one needs to send mails only to a subset of 
> mail-ids from an alias [ALIAS] . The basic intention is only to minimize 
> the complication and difficulty of a mail user when a mail needs to be 
> sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
> from the alias [ALIAS] list.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt

As the draft lacks any indication of where discussion should take
place, I'm sending these comments to the author and the IETF discussion
list, with informational copies to the ietf-822 and ietf-smtp lists.

General comments:

The "draft" fails to conform to requirements as specified in
http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html.  Among the problems
detected by "idnits" are:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Moore | 7 Apr 19:06
Picon

Re: I-D ACTION:draft-arun-ncc-smtp-02.txt

> On Tue April 5 2005 15:30, Internet-Drafts <at> ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > 
> > 
> > 	Title		: Ncc in Mail Header
> > 	Author(s)	: A. Sankar
> > 	Filename	: draft-arun-ncc-smtp-02.txt
> > 	Pages		: 4
> > 	Date		: 2005-4-5
> > 	
> > This draft presents a mechanism to simplify one of the cumbersome 
> > aspects of mailing, when one needs to send mails only to a subset of 
> > mail-ids from an alias [ALIAS] . The basic intention is only to minimize 
> > the complication and difficulty of a mail user when a mail needs to be 
> > sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
> > from the alias [ALIAS] list.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt
> 
> As the draft lacks any indication of where discussion should take
> place, I'm sending these comments to the author and the IETF discussion
> list, with informational copies to the ietf-822 and ietf-smtp lists.

All of your comments miss the most important points - namely that this
proposal breaks layering and it isn't backward compatible with the 
installed base.    For those reasons alone there's no way that this
proposal should be seriously considered.

Keith
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arun Sankar | 8 Apr 11:25
Picon

Re: I-D ACTION:draft-arun-ncc-smtp-02.txt


Hi Keith,

It is definately backward compatiable as there is a Extended SMTP header 
(NCC) that also needs to be in place for the NCC processing to proceed.

Keith Moore wrote:

>>On Tue April 5 2005 15:30, Internet-Drafts <at> ietf.org wrote:
>>    
>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>	Title		: Ncc in Mail Header
>>>	Author(s)	: A. Sankar
>>>	Filename	: draft-arun-ncc-smtp-02.txt
>>>	Pages		: 4
>>>	Date		: 2005-4-5
>>>	
>>>This draft presents a mechanism to simplify one of the cumbersome 
>>>aspects of mailing, when one needs to send mails only to a subset of 
>>>mail-ids from an alias [ALIAS] . The basic intention is only to minimize 
>>>the complication and difficulty of a mail user when a mail needs to be 
>>>sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
>>>from the alias [ALIAS] list.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt
>>>
(Continue reading)

Permalink | Reply | 15 comments |
headers
Keith Moore | 8 Apr 15:16
Picon

Re: I-D ACTION:draft-arun-ncc-smtp-02.txt


[followups redirected to ietf-smtp <at> imc.org list]

On Apr 8, 2005, at 5:25 AM, Arun Sankar wrote:

> It is definately backward compatiable as there is a Extended SMTP 
> header (NCC) that also needs to be in place for the NCC processing to 
> proceed.

no, it is not, in at least two ways:

1. with existing MUAs and other processors that don't display or take 
the Ncc field into account, it creates a mistaken impression that the 
message was sent to recipients that the message was not actually sent 
to

2. because not all systems will support Ncc (either because they 
predated it, or because they think it's not a desirable feature) 
senders might send a message with the mistaken expectation that it will 
not be delivered to particular recipients.

this extension seems of marginal value.  it can be used to attempt 
duplicate suppression, such as when a message arrives at a recipient's 
mailbox both directly and via a list - but it's better to just have 
duplicates suppressed at the recipient's message store.  the other use 
that comes to mind is that people will be tempted to use it as a way to 
implement "send to everyone on this mailing list except that 
troublemaker Joe".  while I sympathize with the desire to do that, it 
will work so unreliably in practice that it's better to not have the 
feature.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 8 Apr 23:43
Picon
Picon

Re: I-D ACTION:draft-arun-ncc-smtp-02.txt


Keith Moore wrote:

> it will work so unreliably in practice that it's better to
> not have the feature.

Indeed.  If a relay supports it, but the next hop doesn't, what
should it do, send me a Potential Unintended Delivery Message ?

                        Bye, Frank
Permalink | Reply | 0 comments |
headers
Hector Santos | 15 Apr 04:36
Favicon

Addressing "Out of office" Vacation accounts


If there any standard, past proposal, effort or otherwise for detecting
auto-reply "vacation" or "out of office" messages?

I understand these two terms:  "vacation" or "out of office" (OOF) is
probably the closet  thing to implementing a partial filter solution.

I am thinking of adding some logic into our list server  but before I do I
would like to know the issues that I can come across.

Besides the obvious of automated disabling of list mail accounts false
positive), what other things would make this unreasonable?

Other questions:

What existing MUA products/software offer built OOF auto-reply features?

What existing list servers have features to support the disabling or making
inactive the list member on vacation?

Is there a past proposal, if not, why having there been a effort to write
one?  It seems like a reasonable consideration.  I would not mind writing a
draft if enough people are interested to pursue it, but I would not care if
anyone wrote it too. I would eagerly anticipate it and support it.

Thanks

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 15 Apr 10:54
Picon
Favicon
Gravatar

Re: Addressing "Out of office" Vacation accounts


Hector Santos writes:
> If there any standard, past proposal, effort or otherwise for 
> detecting auto-reply "vacation" or "out of office" messages?

RFC 3834 suggests one, which won't help you much yet.

You also need a bit of hackery to handle old software. Look for X-Loop 
and Vacation header fields, and some more fields. I don't really 
remember which - it's been a while since I did this.

Arnt
Permalink | Reply | 0 comments |
headers
Keith Moore | 15 Apr 16:49
Picon

Re: Addressing "Out of office" Vacation accounts


> 
> If there any standard, past proposal, effort or otherwise for detecting
> auto-reply "vacation" or "out of office" messages?

I don't know of a good way to _detect_ autoresponses, however there are some
tricks that can be used to discourage autoresponses.

some autoresponders will not respond when they see
"Precedence: junk" or "Precdence: list" in the message header.

another trick is to use a unique MAIL FROM address (different from the 
list address) and to filter mail that is sent to that MAIL FROM address.  
this tends to catch most bounces and some automatic responses.
All mailing lists should be doing this.

of course I recommend testing for RFC 3834's Auto-Submitted field and
also for the Auto: prefix, but that's based on an assumption that people
will actually implement RFC 3834.   It's too early to tell, but I've had
a lot of positive feedback.  And of course part of the reason for writing
this RFC was to encourage more uniformity and thereby enable separate
processing of such notices.  At any rate I don't think it will hurt to
check for these in addition to OOF and other tokens.

Keith
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 21 Apr 23:30
Picon
Picon

Re: I-D ACTION:draft-lilly-legacy-fields-00.txt


Internet-Drafts <at> ietf.org wrote:

> http://www.ietf.org/internet-drafts/draft-lilly-legacy-fields-00.txt

JFTR, my UA still has an "Fcc", I didn't know that this was
documented in RfC 724, tnx for info.

| Appendix B. Disclaimer
|
|   The author is male; any reference to "or she" or "/SHE" in
|   boilerplate of this document is irrelevant.

Good idea, here fighting spam with more spam might work.  Bye.
Permalink | Reply | 2 comments |

Gmane