<Troll alert.>
> On 5/6/2008 10:24 AM, David le Blanc wrote: > >>> BTW, I find recipient validation is not as important as you would > >>> imagine. Certainly mail to unknown users is normally bounced > >>> immediately, but that merely assists in harvesting attacks. > > >> I assume you mean REJECTed, not bounced... but it is a misconception > >> that it 'assists in harvesting attacks... > > > The difference is not important here. A rejection (aka 5.7.1 message rejection from an MTA or MDA) causes the sending party to issue a bounce (which may be the message originators MTA, or any relay in the chain). The other option is for the MTA (relay for you) to accept the message, and generate a bounce locally when the MDA fails to accept the message, the difference is not important. > Your ignorance only contributes to the problem. I'm starting to wonder if it is my writing skills, or your reading skills are coming into question. > > Any legitimate sender will always get an NDR for a failed delivery. > > How do you tell a legitimate from illegitimate sender? One way is > through SAV, which if you implement blindly will wind up getting you > blacklisted if you ever get hit by a real dictionary attack. Ok, you cannot. I should have left the word "legitimate" out. It was meant to imply that the email had successfully passed all SPAM checks. SAV is a pipe-dream. SAV products have been around for a long time and are as dangerous as you say. A more appropriate solution is the elimination of unauthenticated MTAs. However right now, that is almost as great a pipe-dream. (I'm not referring to open relays which are another problem altogether.). > It is IMPOSSIBLE to send an NDR AFTER you have accepted the message for > final delivery. Do you get that? IMPOSSIBLE. An NDR is NOT an EMAIL > message, it is an SMTP Please be specific. An MTA can accept an email message, and then issue and NDR if unable to deliver to the MDA. I agree that an MDA should not accept an email for an invalid user, and then bounce the message. That is wrong. Any MTA may be a MDA, or a relay or both. > What you are doing is sending BOUNCE messages, which in this case is > called BACKSCATTER. Look up backscatter and read it again, then read below. > > Reiterating, I choose NOT to 'REJECT' email based on recipient, but > > rather forward to the email to the appropriate end point which can > > issue an NDR, allowing me to, at some later point in time, to review > > the email, possibly forwarding to the intended (or appropriate) > > recipient. > > If you are simply RELAYING mail, then that is an entirely different > animal, and your description is sorely lacking. Ok. point taken. The perimeter MTA is acting as a relay to protect the MDA's (3 of which, being 'exchange' based, I don't trust from a security standpoint). The perimeter MTA includes both ASSP for validation and an MTA for routing. > If, however, you are doing what it *appears* you are doing - accepting > mail on the server that is authoritative for the recipient then > BOUNCING > certain messages LATER - as opposed performing an SMTP REJECT at the > perimeter - then you ARE, whether you choose to ACCEPT it or REJECT it, > engaging in BACKSCATTER, and are a part of the problem rather than the > solution. Again, point taken. However the MDA does have some flexibility to bounce emails especially when the email is otherwise valid and the MDA encounters an internal error (disk full or quota for example), or if the MDA accepts the email for multiple recipients, and generates an NDR for a subset of those recipients. > > > This appears to be little more than misinformed and thinly veiled > > personal attack. > > What possible reason would I have to personally attack you? I don't > *know* you, all I have to go by are your written words, which - again - > *appear* to be saying that you are engaging in backscatter... Ok, Having read other threads you have participated in, and they generally have the same air of contempt about them, I accept this is not personal. > > "Types of backscatter: > > * Misdirected bounces from spam runs, from mail servers who "accept > then bounce" instead of rejecting mail during the SMTP > transaction." Again, the key here is 'spam runs'. If a non-spam email is rejected by the MTA, or the MDA, it doesn't matter as long as an NDR arrives at the sender's inbox to inform them of the failure. Ironically, even if I reject email at the perimeter, the source server will generate an NDR for the sender, and backscatter will continue. In the event of a spam run, the NDR is misdirected, resulting in backscatter. The difference is important. If the "mail server" of the sender was able to detect that the sender was spamming, and reject the message at the source, then backscatter would be eliminated. Once the spam has entered even the first MTA (relay), backscatter is almost guaranteed as NDR's are required for any which fail delivery. Unfortunately, checking *outbound* mail for spam is a relatively new concept. In fact ASSP and many commercial products use the fact outbound mail is somehow more "trustworthy" and use it to populate whitelists. This is clearly configurable, and up to the admin's discretion. > > This *appears* to be what you are doing. You may be doing some work to > try to limit the damage - you said something above about 'legitimate' > senders - but it doesn't matter, what you are doing - *if* this is > indeed what you are doing - is WRONG. > > > And a hard one for you... > > > > Catchall Email Addresses; > > http://www.homebiztools.com/questions/catchall.htm > > Oh, I know what a ctach-all is, I assure you - and I also know why they > are very, very BAD in 99% of cases (there *are* some legitimate uses > for > them, but NOT on a normal mail server that gets real mail). The catch all is not a tar pit, or a black hole. Every email is received by someone, and handled. No NDR's are generated for invalid recipients because there can be no invalid recipients. If spam gets though, then so be it, however ASSP is very good at what it does. Again, the irony here is that NDR's resulting from ASSP rejecting incoming mail as spam contribute to backscatter, while the catch-all itself does not. > > Your ignorance would be amusing, were it not for the fact that you are > making the spam problem worse. > > Do you really want to continue this? Please have one more go, you know you want to. And we'll leave it there. I've printed your email and have been passing it around for a laugh. My sincerest apologies to the remainder of this email list for me participation in this troll. > > -- > > Best regards, > > Charles > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ > javaone > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
