[unisog] I need help.
Valdis.Kletnieks at vt.edu
Valdis.Kletnieks at vt.edu
Thu Jul 18 21:14:16 GMT 2002
(Disclaimer - I'm not a spam supporter, and I'm well known to be a lot more
hard-line about accepting broken mail than most of the rest of the Sendmail
crew. But you have to be careful who and what you break ;)
On Thu, 18 Jul 2002 14:27:15 MDT, "William D. Colburn (aka Schlake)" said:
> positives. People get far more upset at losing mail than they do at
> receiving spam.
Which is why I commented - there were ways to lose mail in your proposal.. ;)
> I put my telephone number in my anti-spam errors, and people do call
> when they get that error.
Just because you've gotten 2 phone calls doesn't mean you're not losing
mail. That means twice that people have *bothered* to call (possibly
long distance or even trans-ocean) to tell you something is broken.
Do you have a handle on how many times you've bounced the mail, and the
other end has just said "<bleep> it, time to pull that person out of my
address book/mailing list/whatever" and NOT called you?
(As a data point, we run well over 200K pieces of mail a day through our
Listserv box. I probably nuke 5-6 people *a day* off mailing lists because
their mail bounces. It's been at least 3-4 *years* since I've bothered
calling a site to mention the misbehavior - I send an email to postmaster@
and if that doesn't fix it, I figure it's THEIR problem not mine.)
My usual test for this sort of thing is "What does a user in Israel do if
it accidentally nails him"?
(And I haven't even entered into the question of whether the average MUA
will present your bounce message in a format that the end user can make sense
of, or whether the end user is even *ABLE* to do anything at all about the
situation - "I can't fix it, I don't understand it, I know my ISP is clueless,
I guess I won't be mailing Charley anymore"...)
> The RFC also says I have to accept usernames that contain the NULL
> character in them, and I don't do that.
Huh? How do you get that NULL needs to be accepted?
RFC2821, section 4.1.2:
Systems MUST NOT define mailboxes in such a way as to require the use
in SMTP of non-ASCII characters (octets with the high order bit set
to one) or ASCII "control characters" (decimal value 0-31 and 127).
These characters MUST NOT be used in MAIL or RCPT commands or other
commands that require mailbox names.
RFC2822, sections 3.2.1 and 3.4.1 have production rules that don't seem to
allow getting a 0x00 in there either. If you can find a path through the
BNF that gets you a null, please let me know...
> I have wondered about that myself, but it doesn't seem to be causing
> problems that I can see, or that anyone is reporting.
Lack of reporting doesn't mean lack of a problem. I've had to troubleshoot
more than one case where something stupid like Path MTU Discovery was borken,
causing ALL communication to fail, and the remote site's staff had *no* clue that
there was any problem at all. Meanwhile, the poor user at the other end
has no idea what's really going on...
(Have you considered the effect of this on automated mailing lists, many of
which will summarily take a 5xx DSN and unsubscribe the user, leaving nobody
to actually complain?)
> I have a form letter I send to people who block 'MAIL FROM: <>'. :)
How often does the mail to 'postmaster at offending-site' bounce too? ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20020718/fa60e534/attachment-0007.bin
More information about the unisog