Please do not send to me directly, I am on the list. On 10/15/2014 3:15 PM, Jerry Stuckle <jstuc...@attglobal.net> wrote: > On 10/15/2014 12:40 PM, Tanstaafl wrote: >> Easy enough to prove. By all means, quote the actual text of me saying >> this was 'OK'...
> You said: > > "However, once a message has been accepted - ie, *after* the DATA phase > is complete, it should never be bounced, it should be delivered - or, > worse, quarantined, or worst case, deleted (ie, if it is later found to > contain a malicious payload)." And nowhere do you see the word 'OK'. As I said, please do NOT put words in my mouth. > It is either OK to delete an email or it is not. You can't have it both > ways. If, as according to your other statements, it is not OK to delete > emails, then you are violating your own rules by deleting mails - for > ANY reason. If you are unable to see the difference between a rare, extreme worst case scenario of having discovered an email that you accepted for delivery contains a malicious payload, and deleting an email for no other reason than the recipient has a typo in it, then you have no business running a mail server. > Your reason is "i.e. if it is later found to contain a malicious > payload". My reason is "It is addressed to a non-existent user". > Either both are OK or neither is OK. So, you obviously have no business running a mail server. >>>> you keep saying that the RECEIVING server 'sends a message back to >>>> the originator' - unless maybe you simply have a hard time saying >>>> what you really mean, which always causes confusion. >> >>> it does send a message back to the originator - it may only be a >>> status code, but it is still a message. >> >> The status code is not *sent* anywhere - it is a response directly to >> the connecting machine. > Then how does it get back to the sending server? Magic? Can you not read? The CONNECTING MACHINE - the one that was directly talking to YOUR server - is responmsible for that part of the transaction. Spambots DO NOT DO THIS. >> It is then the responsibility of that machine that was talking to your >> server to pass the response code back to the originating *server* (not >> the sender of the email - there is a difference). > I didn't say the sender of the email. Maybe not, but I have no desire to go back through this thread to see whether you ever did or not. You are apparently incapable of communicating with semantic precision, so this time I'm really done. Respond if you like, I won't see it. > And you still can't quote an RFC which indicates what I am doing "breaks > SMTP". That's because there isn't one and I am NOT breaking SMTP. As I said, there is no rule that says that you have to violate an RFC to break SMTP. Accepting invalid recipients then silently deleting them breaks SMTP for the vast majority of internet email users. You are free to break it all you want... on your server. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543f9ffc.6030...@libertytrek.org