Eric,
I actually did some "Soul Searching" on this one. There is a reason to accept "Blank" senders. One reason is that many List Servers do not expose the sender. Also a very important example is a bounce message or warning message. Can you imagine the turmoil if virus warnings had valid return addresses? I don't even want to think about that because I have seen it first hand. I elected to break RFC in this case and flat out reject blank senders. I do not see the issue you are referring to EXCEPT with AOL and we, as an ISP, were able to contact AOL and discuss the issue. It seems that only some of their servers react that way and according to the person I spoke to, this was an artifact of the server and not by design. I am hoping they will fix that but AOL is so huge that it falls into the category of the "headless monster".
When we send out a potentially "Politically turbulent" message to our users, we use a "Do Not Reply" address which forces the user to create a new message, rather than the convenience of hitting the reply button on his mail client.
Having said all that, IF there was an option to "absorb" blank "From Addresses", I would use it but not to save bandwidth as much as to prevent Mail Loops or "Ping-Pongs". It seems that every day, I find yet one more way for an accidental (?) mail loop to start. WebShield, our Virus Scanning SMTP has a registry setting for "Max Loop Count". This prevents the more obvious loops but there are way too many exceptions. The Lotus Notes "Out Of Office" setting is a plague worse than the 17 year locust. The headers get changed to the point that WebShield does not see the loop and all hell breaks loose when 2 people leave for vacation and set their out of office setting and then email each other that they will be out for a week.
But I am rambling ... I am not sure if a change to how the blank from is technically an easy change ... only LogSat knows that. What I am going to look at now is ... Is there some Regular Expression that can get around this problem. I think a global setting may have undesired effects. What really needs to be done it that ALL the RFC's need to be tossed out and somehow the SMTP specification needs to be re-evaluated in it's entirety. The RFC's do not address any of the new problems that forged addresses and spoofed IP's cause. Also, you need to make a career out of following the RFC threads to their actual source and then work forward from there.
Now Here is a real helpful request ... A SPELL CHECKER for the Forum! Then I would not look as illiterate as I am.
This response is an example of why one should limit their Caffeine intake!
Regards, Dan S.
|