At 21:14 2003-03-01 -0800, Ben Crowell did say:
Does anyone have a good recipe for bouncing e-mails from people who don't
give their real name in the From: line?
_real_ name ? Like how do you suggest anyone determine what is real or
not? For that matter, often the email address itself is their name, so
there's no need to have a text version of it (for instance, for personal
correspondance, I often use firstname(_dot_)lastname(_at_)domain(_dot_)tld).
I'm a teacher, and I'm tired of nagging my students not to send
me e-mails from addresses like ppkaka(_at_)aol(_dot_)com (no, I'm not
making that one up!) with no real name listed, and
expect me to know who they are.
Some people _sign_ their emails. You could simply elect to post a policy
of refusing to respond to messages which fail to provide any form of
personal identification (be it in the From:, or in the body).
You should try to keep in mind that many people don't have control of how
their email provider generates the From: - either because they use a
freemail account which doesn't bear their own name, or have a shared
account at home, or their corporate mail system lacks this configuration at
the user level.
Whatever the reason, I think it is rather presumptuous to declare that
people can't send you mail unless their name appears in some syntax _you_
recognize - you're likely to hammer some hapless user who _does_ have their
name in the From:, but just in some format you overlooked.
It is far easier, and much less prone to errors, to simply have the
students _register_ their email address(es) with their names with you when
taking the course, and you rewrite the From: line to include their student
name (and possibly, other identifying info - a student ID number, or
whaever is necessary for you to better categorize them - esp. if this might
be a course where students are submitting homework assignments via
email). This extended id mechanism could be used to file away
correspondance in folders (or an SQL database), and/or update entries in a
database indicating that the user submitted something on time or late or
whatever as per the due time for an assignment (though verifying that the
message actually _contained_ the assignment material is a different matter
- however, at least you'd have a student reference value to key off of).
When I was trying to test my code, I made up a yahoo.com address so I
could send e-mail to myself. (Didn't want to test by sending mail from my
normal address to my normal address, since that could create a loop.)
Suggestion: use a sandbox. You don't even need to _send_ yourself messages
to test the operation, and you don't _actually_ send the autoreplies - they
run through a "sendmail" redefinition and get dumped to a file, allowing
you to review what _would_have_ been sent to sendmail.
As for loops, if you use X-Loop along with logging, you could manage to
ensure that you don't loop on yourself. If you're going to send
autoreplies, you'd better use X-Loop in any event.
studentaddrfile is simply "email_address<space>(parenthesized name)", like so:
bcrowell99(_at_)yahoo(_dot_)com (Ben Crowell)
pooftah(_at_)sexfreak(_dot_)org (Some Inconsiderate Lout)
Students register their email address with you for the class (possibly
through a webpage which generates the above file, if it is too much for you
to transcribe it once a semester), and you might also whitelist their
address (so it doesn't get thrashed as junkmail, say because you have spam
filters as well), AND you have a list of the addresses along with student
names (as above).
Off the top of my head (i.e. not necessarily as optimal as it could be):
:0
* some condition for "addressed to teacher"
{
# extract the From: field AS AN ADDRESS COMPONENT ONLY
FROM=`formail -IReply-To: -rtzxTo:`
# Now, grab the address from our registered address file
# anchored to the beginning of line, AND with a space trailing
# the address, so it should be expected to match a _complete_ address
# component, and not be tricked by a substring of one
# ("user(_at_)domain(_dot_)com" being a substring of
# "someuser(_at_)domain(_dot_)company(_dot_)com" for instance)
NEWFROM=`grep ^"${FROM} " studentaddrfile`
# if NEWFROM isn't empty, rewrite the From: line.
# This rewrites the From: line to your new version (including the
# student name) but retains the original From: as Old-From:
:0f
* ! NEWFROM ?? ^^^^
| formail -i "From: ${NEWFROM}"
# optional, do something if the address ISN'T in our DB.
# (this doesn't mean that their From: doesn't contain desired info,
# just that they're not registered with the From: addr).
#:0E
#| do_something_actions
}
If you have no such "to teacher" condition (say, a plussed address, or a
separate address within a virtual domain), remove the outer condition and
bracing.
One would want to structure things so that this kind of bounce happens
only to e-mails we're pretty sure are not spam.
Whitelisting the _registered_ student addresses would be a good way to do
that - however, in doing so, you deftly eliminate the problem since you can
rewrite the From: as demonstrated above. Thus, no need to bounce anything,
no risk of bouncing messages to people who really shouldn't be assaulted
because you don't like the addressing of their messages, which they may not
be able to directly control.
BTW, _YOUR_ yahoo message arrived with an _unquoted_ name:
Ben Crowell <bcrowell99(_at_)yahoo(_dot_)com>
vs.
"Ben Crowell" <bcrowell99(_at_)yahoo(_dot_)com>
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail