On 5/6/2008 10:09 PM, David le Blanc wrote: > <Troll alert.> Lol... my attempt to clear up your confusion about what constitutes backscatter doesn't make me a troll, David.
The simple fact is, if you took this argument over to the postfix list, they would be much less patient than I have been. Don't believe me? Go give it a try... > 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). Part right, part wrong. A (properly configured) 'relay' will only 'relay' the SMTP REJECT, it will *never* generate an NDR. Only the *originating* MTA should *ever* generate an NDR - and this fact appears to be the source of your confusion, because this comment appears numerous times in the following text... > 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 comprehension problem apparently is ignorance about what is and is not a genuine NDR (the difference between a 'hard bounce' and a 'soft bounce'), the difference between an *authoritative* MTA and an MTA acting as a simple relay, and lastly, how an SMTP transaction is designed to work. Lets try again... ASSP is designed to be used as an SMTP Proxy - as a proxy to the authoritative MTA - meaning, the public IP address of the MX record for your domain points to your ASSP server. This means that it is acting, by definition, as the authoritative MTA. This isn't up for debate. If you disagree, then this is where your comprehension breaks down, and why you are arguing with me about this, and means that *hopefully* you don't disagree with the following (admittedly simplified) description of the typical SMTP transaction: 1. UserA sends an email to UserB 2. UserA's public MTA (MTA-A) initiates contact with UserB's public MTA (MTA-B) 3. Any MTA's *in* *between* - whether in between either of the Users Mail Client and said Users public MTA, or in between the two public MTA's - are called 'relay' MTA's, and are irrelevant for purposes of this discussion (meaning we'll assume they are properly configured)... 4. Once the message makes its way to MTA-B, MTA-B can only ACCEPT or REJECT (or DEFER) it 5. If the message is REJECTed, then that REJECT will be relayed back to MTA-A, and *MTA-A* will generate the NDR to UserA. 6. IF MTA-B ACCEPTS THE MESSAGE, THEN LATER AN NDR IS GENERATED (WHETHER BY MTA-B ITSELF OR ANYTHING THAT MIGHT BE BEHIND IT, like your Exchange server), THAT NDR IS, BY DEFINITION, BACKSCATTER. P.E.R.I.O.D. >> 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. Performing body checks (bayesian spam filtering) is only possible on a message that has already been accepted by the authoritative MTA for that recipient/domain - and there is nothing wrong with this, everyone does it. But if you BOUNCE the message if it fails any of the body checks you are performing, *that* *is*, by *definition*, *backscatter*. >> 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. Again... *Only* the *ORIGINATING* MTA (meaning, *NOT* *YOURS*) can generate *LEGITIMATE* NDR's for messages it *originates*. >> 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. Whether or not an MTA is a 'relay' is not a matter of semantics, or how you personally choose to define it - it is a matter of function and configuration. If you are using ASSP as the 'perimeter' receiver for your domains - meaning, its public IP is the IP your MX records point to - then by definition, it *is* *not* *a* *relay*. >> 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. YOUR SERVER SHOULD NOT GENERATE NDR's FOR MESSAGES THAT IT DID NOT ORIGINATE. If it does, IT IS ENGAGING IN (a form of) BACKSCATTER. It can only ACCEPT OR REJECT (or DEFER) them. > 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. Yes, I have contempt for deliberate ignorance. >> "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'. Wrong. The key here *for *you* is the very next part - "...mail servers who "accept then bounce" instead of rejecting mail during the smtp transaction." How many times do I have to repeat this? > 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. Wrong. You can only REJECT a message during the SMTP transaction. This is *not* a matter of semantics, as you seem to want it to be. > Ironically, even if I reject email at the perimeter, Ironically, the perimeter is the *only* place you can REJECT a message. Once it has been ACCEPTed, you can only BOUNCE it - which, *again*, is, by definition, BACKSCATTER. > the source server will generate an NDR for the sender, and > backscatter will continue. Sorry, but that is *not* backscatter - in point of fact, that is the ONLY LEGITIMATE WAY THAT AN NDR SHOULD EVER BE GENERATED. > In the event of a spam run, the NDR is misdirected, resulting in > backscatter. Wrong. An SMTP REJECT is *not* an *email* *message*, it is a simple SMTP response that is relayed back to the originating MTA, which is the one *responsible for generating NDRs* for messages it *originated*. In the event of a spam run, since the 'originating MTA' is almost always a botnet zombie, NO NDR will EVER reach the poor innocent forged sender. > The difference is important. Yes, it is... > 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. This is why most ISP's close (or are closing) outbound port 25 for their customers - and why they should have done so a long time ago, and why it should be a LAW that they do so. They should only allow outbound port 25 traffic for commercial accounts or customers who make specific arrangements, and said traffic should be carefully monitored for spam. All other (residential) customers should be required to relay outbound mail through their smtp servers. Said relays should, imnsho, be required to be authenticated (username/password), and should *also* be carefully monitored for spam/unusual activity. > Once the spam has entered even the first MTA (relay), backscatter is > almost guaranteed as NDR's are required for any which fail delivery. NDRs will only be generated by REAL SMTP servers, not botnet zombies (the majority source of spam today) - and if they are configured properly, will NOT generate NDRs for said spam, because they will not SEND said spam. > Unfortunately, checking *outbound* mail for spam is a relatively new > concept. Not for ISPs (the main ones who should be dong so)... > 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 is astounding. 99+% of the messages that ASSP rejects as spam will NEVER generate an NDR, because the originating MTA is not a real MTA, and only the originating MTA (or a misconfigured authoritative MTA) can generate NDRs. >> 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. The laugh is on you, David... maybe one of your friends your passing these messages along to will take you to the side and tell you, maybe not... Oh, I forgot, your an Exchange 'admin'... which means you are possibly relying on Microsoft only documentation about SMTP, which could very well account for your flawed understanding of this issue... -- 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
