Header check of To:

[Joseph Brennan]

I am trying to do a simple check of the To header for presence
of an @ sign. I get an unexpected error.

Sendmail 8.12.3.

SLocal_localaddr
Khasnoat regex -a@MATCH -n .+@.+
HTo: $>check_header_To
Scheck_header_To
R$* : ; $* $@ OK special-case :; addressing
R$+ $: $&{auth_type} $| $1
R$+ $| $+ $@ OK authenticated is OK
R$* $| $+ $: $(hasnoat $2 $: $2 $) no @ in To header?
R@MATCH $#error $@ 5.1.3 $: "553 Unqualified header To"

In most cases, this works as expected. Test messages with one
or two recipients are rejected or accepted as designed and the
accepted messages do not have any mangling of their To header.

In a few cases, an error message is logged, as below. This message
had 16 recipients and this error was logged 16 times. The To of
the original was written correctly with balanced <>.

Nov 20 10:22:53 brazilnut sm-mta[7748]: [ID 801593 mail.info] gAKFMoGW007748: to=<xx...@columbia.edu>, delay=00:00:02, pri=481421, stat="Xxxxxx Xxxxx"<xx...@columbia.edu>,"Xxxxxx Xxxxx"<xx...@columbia.edu>,"Xxxxxx Xxxxxxx"<xxx...@xx.xx...Xxxxxxxxx"<xx...@columbia.edu>,"Xxxx Xxxxxxxx"<xx...@columbia.edu>,"Xxxxxxxx Xxxxx"<... Unbalanced '<'

I am required to hide the real addresses, but there is an X for
each original character, and spacing is preserved. Note the
unbalanced, truncated address before the first "...", and a
series of different addresses up to another truncation at
the second and final "...".

What's doing this? What would fix it?

Joseph Brennan Postmaster Academic Information Systems
Columbia University in the City of New York
postm...@columbia.edu

[D. Stussy]

On 20 Nov 2002, Joseph Brennan wrote:
>I am trying to do a simple check of the To header for presence
>of an @ sign. I get an unexpected error.
>
>Sendmail 8.12.3.
>
>SLocal_localaddr
>Khasnoat regex -a@MATCH -n .+@.+

I would have written the expression as "(.+)\@(.+)" just to be clear. Try it
that way too and see if the results are the same.

Also, if you want the result of the -a flag to be returned in PLACE of whatever
is passed, don't you also need the -m flag?

>HTo: $>check_header_To
>Scheck_header_To

Inserting the following rule may also help:
R$@ $#whatever.....
Why do any further comparisons if the field RHS is null?

[PS: As far as I can tell, the ONLY header which may have an empty RHS is
"Bcc:", so the "#whatever" should probably be "#error ...".]

[Joseph Brennan]

D. Stussy <kd6...@att.net> wrote:
>[PS: As far as I can tell, the ONLY header which may have an empty RHS is
>"Bcc:", so the "#whatever" should probably be "#error ...".]

Thanks for your reply.

Regarding a To: header with nothing after it, it my reading also of
RFC 822 and 2822 that if it exists it must have content (where an
emtpy ":;" group counts as content). But two important products can
generate empty To: headers: Outlook, and an academic course support
web product called Blackboard. So any attempts to reject on an empty
To: header will drop some real mail, unless exceptions are built in.

Mail with some content after To: but without "@" is pretty much all
garbage. It's important that locally generated mail pass through a
submit.cf that fully qualifies addresses. PC mail clients do a good
job of qualifying their output; very very little comes in without.

[D. Stussy]

On 20 Nov 2002, Joseph Brennan wrote:

>D. Stussy <kd6...@att.net> wrote:
>>[PS: As far as I can tell, the ONLY header which may have an empty RHS is
>>"Bcc:", so the "#whatever" should probably be "#error ...".]
>
>Thanks for your reply.
>
>Regarding a To: header with nothing after it, it my reading also of
>RFC 822 and 2822 that if it exists it must have content (where an
>emtpy ":;" group counts as content). But two important products can
>generate empty To: headers: Outlook, and an academic course support
>web product called Blackboard. So any attempts to reject on an empty
>To: header will drop some real mail, unless exceptions are built in.

Personally, if Outlook will generate a "To:" with a blank RHS, then it isn't RFC
and the message deserves to be dropped. Microsoft has to learn that they need
to adhere to the standards and that they don't create them. I haven't heard of
Blackboard.

Only "Bcc:" may have a blank RHS.

>Mail with some content after To: but without "@" is pretty much all
>garbage. It's important that locally generated mail pass through a
>submit.cf that fully qualifies addresses. PC mail clients do a good
>job of qualifying their output; very very little comes in without.

I may agree, noting that your rules already make an exception for mailing lists
that have ":;" in them. However, I'd look back at the BNF specification of the
header's data field before I put in such a rule - because if it's syntactically
valid not to have an "@" (without a list specification), then it may be a bad
rule.

One of the spammers out there that hit my server once included double quotes on
his "To:" RHS without anything between them - e.g. "". I now reject that - on
the grounds that there must be something quoted when quotes are used; otherwise,
what's the point of having the quotes? I do admit that I didn't check the BNF
to see if "null-double-quotes" is syntactically valid, but to me, it is
semantically invalid and thus deserving of a "554 5.7.1 ..." error response.