Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2770 > unrolled thread

ping Moe Trin

Back to article view | Back to comp.os.linux.networking

Contents

  ping Moe Trin buck <buck@private.mil> - 2014-03-05 19:26 +0000
    Re: ping Moe Trin Thad Floryan <thad@thadlabs.com> - 2014-03-05 13:44 -0800
      Re: ping Moe Trin Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-03-05 22:15 +0000
        Re: ping Moe Trin Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-03-06 01:50 +0000
          Re: ping Moe Trin buck <buck@private.mil> - 2014-03-06 07:19 +0000
            Re: ping Moe Trin David Brown <david.brown@hesbynett.no> - 2014-03-06 09:38 +0100
            Re: ping Moe Trin Richard Kettlewell <rjk@greenend.org.uk> - 2014-03-06 09:54 +0000
            Re: ping Moe Trin William Unruh <unruh@invalid.ca> - 2014-03-06 17:43 +0000
          Re: ping Moe Trin Rick Jones <rick.jones2@hp.com> - 2014-03-06 19:23 +0000
            Re: ping Moe Trin buck <buck@private.mil> - 2014-03-06 20:33 +0000
              Re: ping Moe Trin Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-03-07 02:52 +0000
                Re: ping Moe Trin "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> - 2014-03-07 14:09 -0800
                  Re: ping Moe Trin Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-03-08 20:58 +0000
                    Re: ping Moe Trin Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-03-09 01:53 +0000
            Re: ping Moe Trin Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-03-07 00:22 +0000

#2770 — ping Moe Trin

I am searching for an RFC that says an Email header may contain a blank 
SENDER.  I'm sure I read that the SMTP server must not reject messages 
where the SENDER is blank, but darned if I can find it now.

Can you please provide a link (or your usual better information)?
-- 
buck

[toc] | [next] | [standalone]

#2771

On 3/5/2014 11:26 AM, buck wrote:
> I am searching for an RFC that says an Email header may contain a blank 
> SENDER.  I'm sure I read that the SMTP server must not reject messages 
> where the SENDER is blank, but darned if I can find it now.
> 
> Can you please provide a link (or your usual better information)?

I'm not Moe but your question interested me.

Googling "RFC that says an Email header may contain a blank SENDER"
without the quotes provides what you seek.

Thad

[toc] | [prev] | [next] | [standalone]

#2772

On Wed, 2014-03-05, Thad Floryan wrote:
> On 3/5/2014 11:26 AM, buck wrote:
>> I am searching for an RFC that says an Email header may contain a blank 
>> SENDER.  I'm sure I read that the SMTP server must not reject messages 
>> where the SENDER is blank, but darned if I can find it now.
>> 
>> Can you please provide a link (or your usual better information)?
>
> I'm not Moe but your question interested me.
>
> Googling "RFC that says an Email header may contain a blank SENDER"
> without the quotes provides what you seek.

Which of the hits, and will the answer be "yes" or "no"?  I'm asking
because his question is ambiguous: is he talking about the "Sender:"
header or about any header providing some kind of information about
the sender (From:, Sender:, possibly others)?  And what's his
definition of "blank"?

Personally I'd check RFC 5322 section 3.6.2.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2773

On 5 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<slrnlhf8fq.81f.grahn+nntp@frailea.sa.invalid>, Jorgen Grahn wrote:

>Thad Floryan wrote:

>> buck wrote:

>>> I am searching for an RFC that says an Email header may contain a
>>> blank SENDER.  I'm sure I read that the SMTP server must not reject
>>> messages  where the SENDER is blank, but darned if I can find it
>>> now.

I wonder if you are referring to section 6.4 of RFC5321. which is sort
of based on "The Robustness Principle" (see RFC1122 section 1.2.2)
originally attributed to Jon Postal:

                "Be liberal in what you accept, and
                 conservative in what you send"

>> Googling "RFC that says an Email header may contain a blank SENDER"
>> without the quotes provides what you seek.

>Which of the hits, and will the answer be "yes" or "no"?  I'm asking
>because his question is ambiguous: is he talking about the "Sender:"
>header or about any header providing some kind of information about
>the sender (From:, Sender:, possibly others)?

I'll agree that the question is ambiguous.   "Sender:" isn't a
"required" header in all cases, and may be missing in many cases.
"From:" on the other hand...

>Personally I'd check RFC 5322 section 3.6.2.

  6854 Update to Internet Message Format to Allow Group Syntax in the
       "From:" and "Sender:" Header Fields. B. Leiba. March 2013.
       (Format: TXT=20190 bytes) (Updates RFC5322) (Status: PROPOSED
       STANDARD)

  Abstract

   The Internet Message Format (RFC 5322) allows "group" syntax in some
   email header fields, such as "To:" and "CC:", but not in "From:" or
   "Sender:".  This document updates RFC 5322 to relax that restriction,
   allowing group syntax in those latter fields, as well as in
   "Resent-From:" and "Resent-Sender:", in certain situations.

On the other hand,

   The Internet Message Format, as far back as RFC 822 [RFC0822], has
   always required a usable address to appear in the "From:" header
   field of messages in order to allow replies to be sent.  To this end,
   the syntax of messages, up to and including the current specification
   [RFC5322], has required the use of the mailbox address form in the
   originator ("From:" and "Sender:") fields of messages and has
   specifically forbidden the use of the group address form, which
   permits an empty list of addresses (that is, an address list with no
   address included that might be used for a reply).

   However, the use cases for the "From:" field have evolved.  There are
   numerous instances of automated systems that wish to send email but
   cannot handle replies, and a "From:" field with no usable addresses
   would be extremely useful for that purpose.

But you also want to look at the SMTP transaction (RFC5321, section
3.3) about the "MAIL FROM" dialog.

So "buck", care to clarify the question?

        Old guy

[toc] | [prev] | [next] | [standalone]

#2774

Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote in
news:slrnlhfl3f.cij.ibuprofin@fermi.phx.az.us: 

> On 5 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in
> article <slrnlhf8fq.81f.grahn+nntp@frailea.sa.invalid>, Jorgen Grahn
> wrote: 
> 
>>Thad Floryan wrote:
> 
>>> buck wrote:
> 
>>>> I am searching for an RFC that says an Email header may contain a
>>>> blank SENDER.  I'm sure I read that the SMTP server must not 
reject
>>>> messages  where the SENDER is blank, but darned if I can find it
>>>> now.
> 
> I wonder if you are referring to section 6.4 of RFC5321. which is 
sort
> of based on "The Robustness Principle" (see RFC1122 section 1.2.2)
> originally attributed to Jon Postal:
> 
>                 "Be liberal in what you accept, and
>                  conservative in what you send"
> 
>>> Googling "RFC that says an Email header may contain a blank 
SENDER"
>>> without the quotes provides what you seek.
> 
>>Which of the hits, and will the answer be "yes" or "no"?  I'm asking
>>because his question is ambiguous: is he talking about the "Sender:"
>>header or about any header providing some kind of information about
>>the sender (From:, Sender:, possibly others)?
> 
> I'll agree that the question is ambiguous.   "Sender:" isn't a
> "required" header in all cases, and may be missing in many cases.
> "From:" on the other hand...
> 
>>Personally I'd check RFC 5322 section 3.6.2.
> 
>   6854 Update to Internet Message Format to Allow Group Syntax in 
the
>        "From:" and "Sender:" Header Fields. B. Leiba. March 2013.
>        (Format: TXT=20190 bytes) (Updates RFC5322) (Status: PROPOSED
>        STANDARD)
> 
>   Abstract
> 
>    The Internet Message Format (RFC 5322) allows "group" syntax in
>    some email header fields, such as "To:" and "CC:", but not in
>    "From:" or "Sender:".  This document updates RFC 5322 to relax 
that
>    restriction, allowing group syntax in those latter fields, as 
well
>    as in "Resent-From:" and "Resent-Sender:", in certain situations.
> 
> On the other hand,
> 
>    The Internet Message Format, as far back as RFC 822 [RFC0822], 
has
>    always required a usable address to appear in the "From:" header
>    field of messages in order to allow replies to be sent.  To this
>    end, the syntax of messages, up to and including the current
>    specification [RFC5322], has required the use of the mailbox
>    address form in the originator ("From:" and "Sender:") fields of
>    messages and has specifically forbidden the use of the group
>    address form, which permits an empty list of addresses (that is, 
an
>    address list with no address included that might be used for a
>    reply). 
> 
>    However, the use cases for the "From:" field have evolved.  There
>    are numerous instances of automated systems that wish to send 
email
>    but cannot handle replies, and a "From:" field with no usable
>    addresses would be extremely useful for that purpose.
> 
> But you also want to look at the SMTP transaction (RFC5321, section
> 3.3) about the "MAIL FROM" dialog.
> 
> So "buck", care to clarify the question?
> 
>         Old guy
> 

Let me read the RFCs referenced in replies to my question, after which 
I
will reply more carefully. 

Meantime, from a moral standpoint I wish to insist that if the sender
refuses to identify that I may discard the message without having
violated any internet standard. -- 
buck

[toc] | [prev] | [next] | [standalone]

#2775

On 06/03/14 08:19, buck wrote:
> Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote in
> news:slrnlhfl3f.cij.ibuprofin@fermi.phx.az.us: 
> 
>> On 5 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in
>> article <slrnlhf8fq.81f.grahn+nntp@frailea.sa.invalid>, Jorgen Grahn
>> wrote: 
>>
>>> Thad Floryan wrote:
>>
>>>> buck wrote:
>>
>>>>> I am searching for an RFC that says an Email header may contain a
>>>>> blank SENDER.  I'm sure I read that the SMTP server must not 
> reject
>>>>> messages  where the SENDER is blank, but darned if I can find it
>>>>> now.
>>
<snip>
>> So "buck", care to clarify the question?
>>
>>         Old guy
>>
> 
> Let me read the RFCs referenced in replies to my question, after which 
> I
> will reply more carefully. 
> 
> Meantime, from a moral standpoint I wish to insist that if the sender
> refuses to identify that I may discard the message without having
> violated any internet standard. -- 
> buck
> 

If you are setting up an SMTP server, you are allowed to make your own
rules - you just can't justify non-standard rules by claiming they
violate the standards.  It is fine - and normal practice - for a server
to implement stricter rules than the standards say.  For example, you
can reject mails that based on sender or receiver addresses, or sizes,
or attachments, or message contents (such as spam or malware).  It is
perfectly reasonable for you to reject mail that does not have a sender.
 (Note, of course, that having a "sender" field does not mean the
incoming mail is being honest about the sender.)

If you are /writing/ an SMTP server, then perhaps you should at least
allow the administrator an option to let the server accept emails
without a sender if you want to say it fully supports all relevant
RFC's.  But I don't think it is unreasonable for this option to be off
by default.

[toc] | [prev] | [next] | [standalone]

#2776

buck <buck@private.mil> writes:
> Let me read the RFCs referenced in replies to my question, after which
> I will reply more carefully.
>
> Meantime, from a moral standpoint I wish to insist that if the sender
> refuses to identify that I may discard the message without having
> violated any internet standard.

The From: field is mandatory, and must not be empty.  (5322 3.6, 3.6.2.)

The Sender: field is only mandatory if the From: field contains more
than one address.  If it is present it must not be empty.  (5322 3.6.2)

The return path (in the SMTP ‘MAIL FROM’ command) may be empty (5321
4.5.5).


None of this tells you who the message is really from, since in practice
the real sender can put anything they like in these fields.

You can discard any message you like according to any criteria you
choose, the question is not whether you are violating any Internet rules
but what you (or your users) want to read.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#2777

On 2014-03-06, buck <buck@private.mil> wrote:
> Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote in
> news:slrnlhfl3f.cij.ibuprofin@fermi.phx.az.us: 
>
......
>> 
>
> Let me read the RFCs referenced in replies to my question, after which 
> I
> will reply more carefully. 
>
> Meantime, from a moral standpoint I wish to insist that if the sender
> refuses to identify that I may discard the message without having
> violated any internet standard. -- 
> buck

You may do what you wish with messages sent to you. Send them all to the
bitbucket if your wish. RFCs say nothing about what is done with
messages once they are received. Only about their format (not content)
while they are in transit so that they can get from sender to recipient. 

[toc] | [prev] | [next] | [standalone]

#2778

Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
> I wonder if you are referring to section 6.4 of RFC5321. which is
> sort of based on "The Robustness Principle" (see RFC1122 section
> 1.2.2) originally attributed to Jon Postal:

Postel?-)  Though this thread would put mail on the brain :)

>                 "Be liberal in what you accept, and
>                  conservative in what you send"

rick jones
-- 
Process shall set you free from the need for rational thought. 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[toc] | [prev] | [next] | [standalone]

#2779

On 3/5/2014 11:26 AM, buck wrote:
> I'm sure I read that the SMTP server must not reject messages where 
the SENDER is blank

From RFC 5322 and replies, it appears that I had this backwards.  If my 
understanding of 5322 is correct, at least one of the SENDER headers 
MUST contain a "valid" Email address.

Valid is in quotes because, as Richard Kettlewell said
"None of this tells you who the message is really from, since in 
practice the real sender can put anything they like in these fields."

Thanks for the replies.
-- 
buck

[toc] | [prev] | [next] | [standalone]

#2781

On 6 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<lfam3802snq@news6.newsguy.com>, buck wrote:

>From RFC 5322 and replies, it appears that I had this backwards.  If my
>understanding of 5322 is correct, at least one of the SENDER headers 
>MUST contain a "valid" Email address.

Ah, but carefully read section 4 of RFC6854.  Section 2.1 of that
document _replaces_ section 3.6.2. of RFC5322.   I don't know about
you, but I've received mail with an intentionally invalid return
address  (usually something like "No-Reply-Accepted@example.com" or
"Not-A-Valid-Mailbox@example.com").  One recent mail was from the
Arizona Department of Revenue - advising me that they had received my
electronically filed (state income) tax return.

>Valid is in quotes because, as Richard Kettlewell said
>"None of this tells you who the message is really from, since in 
>practice the real sender can put anything they like in these fields."

Back when the Usenet newsgroup "news.admin.net-abuse.blocklisting"
existed, one of the standard responses was "my server - my rules".
If you wanted to only accept mail from hosts that _didn't_ have a
specific letter in their name or specific number in their IP address,
you could do so.   (I'd say those letters/numbers are against my
religion, but the governor just vetoed that bill last month.)  ;-)

        Old guy

[toc] | [prev] | [next] | [standalone]

#2782

In article <slrnlhid3q.1of.ibuprofin@fermi.phx.az.us>,
ibuprofin@painkiller.example.tld.invalid (Moe Trin) writes:

> On 6 Mar 2014, in the Usenet newsgroup comp.os.linux.networking,
> in article <lfam3802snq@news6.newsguy.com>, buck wrote:
>
>> From RFC 5322 and replies, it appears that I had this backwards.
>> If my understanding of 5322 is correct, at least one of the SENDER
>> headers MUST contain a "valid" Email address.
>
> Ah, but carefully read section 4 of RFC6854.  Section 2.1 of that
> document _replaces_ section 3.6.2. of RFC5322.   I don't know about
> you, but I've received mail with an intentionally invalid return
> address  (usually something like "No-Reply-Accepted@example.com" or
> "Not-A-Valid-Mailbox@example.com").  One recent mail was from the
> Arizona Department of Revenue - advising me that they had received
> my electronically filed (state income) tax return.

I get statements from the local authority that collects bridge tolls.
The sender address is <donotreply@treo.ca>.

I think it all comes down to what you mean by "invalid".
Addresses like the examples above might not actually exist,
but they are not _syntactically_ invalid, and the RFCs tend
to deal with syntax above all else.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#2792

On Fri, 2014-03-07, Charlie Gibbs wrote:
> In article <slrnlhid3q.1of.ibuprofin@fermi.phx.az.us>,
> ibuprofin@painkiller.example.tld.invalid (Moe Trin) writes:
>
>> On 6 Mar 2014, in the Usenet newsgroup comp.os.linux.networking,
>> in article <lfam3802snq@news6.newsguy.com>, buck wrote:
>>
>>> From RFC 5322 and replies, it appears that I had this backwards.
>>> If my understanding of 5322 is correct, at least one of the SENDER
>>> headers MUST contain a "valid" Email address.
>>
>> Ah, but carefully read section 4 of RFC6854.  Section 2.1 of that
>> document _replaces_ section 3.6.2. of RFC5322.   I don't know about
>> you, but I've received mail with an intentionally invalid return
>> address  (usually something like "No-Reply-Accepted@example.com" or
>> "Not-A-Valid-Mailbox@example.com").  One recent mail was from the
>> Arizona Department of Revenue - advising me that they had received
>> my electronically filed (state income) tax return.
>
> I get statements from the local authority that collects bridge tolls.
> The sender address is <donotreply@treo.ca>.
>
> I think it all comes down to what you mean by "invalid".
> Addresses like the examples above might not actually exist,
> but they are not _syntactically_ invalid, and the RFCs tend
> to deal with syntax above all else.

IMO they deal a lot with semantics too.  Those addresses are "mailbox
names" (I think that's the term the RFCs use) and you can send a mail
in that general direction.  But the RFCs cannot guarantee that such a
mailbox also /exists/ and is in working order at the time when you
want to place mail into it.

Slight topic change: isn't there a standard way of saying "you cannot
reply to this mail?"  How about group syntax?

  Reply-to: Noone:;

which would be a parallel to

  Cc: Undisclosed recipients:;

I think we can agree that the <donotreply@treo.ca> practice is common
and annoying ... although less annoying than giving the name of a
proper mailbox which noone reads.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2794

On 8 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in article
<slrnlhn13m.81f.grahn+nntp@frailea.sa.invalid>, Jorgen Grahn wrote:

>Charlie Gibbs wrote:

>> ibuprofin@painkiller.example.tld.invalid (Moe Trin) writes:

>>> Ah, but carefully read section 4 of RFC6854.  Section 2.1 of that
>>> document _replaces_ section 3.6.2. of RFC5322.

>> I think it all comes down to what you mean by "invalid".
>> Addresses like the examples above might not actually exist,
>> but they are not _syntactically_ invalid, and the RFCs tend
>> to deal with syntax above all else.

>IMO they deal a lot with semantics too.  Those addresses are "mailbox
>names" (I think that's the term the RFCs use)

yes

>you can send a mail in that general direction.  But the RFCs cannot
>guarantee that such a mailbox also /exists/ and is in working order
>at the time when you want to place mail into it.

Never has been required. See section 4.5.1 of RFC5322, which requires
an SMTP server to _accept_ mail for "postmaster", but

   SMTP systems are expected to make every reasonable effort to accept
   mail directed to Postmaster from any other system on the Internet.

that doesn't say that a person MUST read the mail, much less actually
receive it.    Ignore-bots have existed as long as mail has - and I'm
referring to snail-mail as well.

>Slight topic change: isn't there a standard way of saying "you cannot
>reply to this mail?"

No, RFC2142 lists "valid" names. There is no RFC (or consensus) for a
non-valid name.   ;-)

>How about group syntax?

See section 4 of RFC6854.

>I think we can agree that the <donotreply@treo.ca> practice is common
>and annoying ... although less annoying than giving the name of a
>proper mailbox which noone reads.

Heard recently of someone who was trying to get a job.  They responded
to an ad, and received a reply...   heck, here's his tale of woe:

  The e-mail included this text:

  >Please respond and let me know, if there are any upcoming dates that
  >you are unavailable.

  The entire line was boldface, and the word "respond" was also
  underlined (as was the "un" in "unavailable").

  So I replied.

  Today, they asked if I was still interested, as they had not heard
  from me.

  Only then did I notice that the original e-mail (the one that I was
  specifically asked to "respond" to) was sent from:

  NoReply-Recruiting@bitbucket.company.com

Not sure that's a good company to work for.      ;-)

        Old guy

[toc] | [prev] | [next] | [standalone]

#2780

On Thu, 6 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <lfahvf$ocf$1@usenet01.boi.hp.com>, Rick Jones wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

>> I wonder if you are referring to section 6.4 of RFC5321. which is
>> sort of based on "The Robustness Principle" (see RFC1122 section
>> 1.2.2) originally attributed to Jon Postal:

>Postel?-)  Though this thread would put mail on the brain :)

Subliminal suggestion - nails you every time.

>>                 "Be liberal in what you accept, and
>>                  conservative in what you send"

See!   Has "mail" written all over the place.

For others wondering WTF, see RFC2468

  2468 I REMEMBER IANA. V. Cerf. October 1998. (Format: TXT=8543 bytes)
       (Status: INFORMATIONAL)

or check his wiki-page: http://en.wikipedia.org/wiki/Jon_Postel
Jon died of heart problems at age 55 in 1998.

        Old guy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web