ping Moe Trin

Discussion in 'Linux Networking' started by buck, Mar 5, 2014.

  1. buck

    buck Guest

    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, Mar 5, 2014
    1. Advertisements

  2. buck

    Thad Floryan Guest

    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 Floryan, Mar 5, 2014
    1. Advertisements

  3. buck

    Jorgen Grahn Guest

    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 Grahn, Mar 5, 2014
  4. buck

    Moe Trin Guest

    On 5 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    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"
    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...
    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


    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
    Moe Trin, Mar 6, 2014
  5. buck

    buck Guest

    Let me read the RFCs referenced in replies to my question, after which
    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, Mar 6, 2014
  6. buck

    David Brown Guest

    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.
    David Brown, Mar 6, 2014
  7. 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

    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.
    Richard Kettlewell, Mar 6, 2014
  8. 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.
    William Unruh, Mar 6, 2014
  9. buck

    Rick Jones Guest

    Postel?-) Though this thread would put mail on the brain :)
    rick jones
    Rick Jones, Mar 6, 2014
  10. buck

    buck Guest

    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, Mar 6, 2014
  11. buck

    Moe Trin Guest

    On Thu, 6 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in
    Subliminal suggestion - nails you every time.

    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)

    or check his wiki-page:
    Jon died of heart problems at age 55 in 1998.

    Old guy
    Moe Trin, Mar 7, 2014
  12. buck

    Moe Trin Guest

    On 6 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    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 "" or
    ""). One recent mail was from the
    Arizona Department of Revenue - advising me that they had received my
    electronically filed (state income) tax return.
    Back when the Usenet newsgroup ""
    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
    Moe Trin, Mar 7, 2014
  13. I get statements from the local authority that collects bridge tolls.
    The sender address is <>.

    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.
    Charlie Gibbs, Mar 7, 2014
  14. buck

    Jorgen Grahn Guest

    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 <> practice is common
    and annoying ... although less annoying than giving the name of a
    proper mailbox which noone reads.

    Jorgen Grahn, Mar 8, 2014
  15. buck

    Moe Trin Guest

    On 8 Mar 2014, in the Usenet newsgroup comp.os.linux.networking, in article
    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.
    No, RFC2142 lists "valid" names. There is no RFC (or consensus) for a
    non-valid name. ;-)
    See section 4 of RFC6854.
    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:
    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:

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

    Old guy
    Moe Trin, Mar 9, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.