> If you don't have bash, the -t timeout parameter will need to be removed > from the read, and you'll have to work out some other way of timing out > the whole process.
If he has a UNIX system worthy of that qualification :-), he probably has line(1) [1] which also has a -t timeout parameter.
Indeed. I have also replied many times that I was asking about a solution not using (x)inetd.
> One would think if a server is not listening on port 25, it would be > obvious that it is not accepting email. Additionally, email > transmission is not a random selection of hosts to see whether this > particular host accept email for a particular domain.
One would think. However, this discussion started out as a discussion in response to reading an RFC. I know that SMTP traffic is usually not random. However this is just a discussion thread.
> you could use read to see what is being sent in and deal with it > accordingly, but if it has not been made clear, this is an excersise in > futility.
Lots of things are an exercise in futility, yet they happen.
> If there were RFC's of similar context dealing with other services web, > ftp, pop3d, imap, etc., would you be exploring implementing those that > as well just out of curiosity?
I don't believe any other protocol defines the lack of being able to get a permanent error out of a server as a temporary condition like SMTP does. If this was not the case, I suspect that such would exist for other protocols as well.
Frank Slootweg <t...@ddress.is.invalid> wrote: > If he has a UNIX system worthy of that qualification :-), he probably > has line(1) [1] which also has a -t timeout parameter. > [1] line(1) is SVID*/XPG*.
Strange. I thought Sun provided XPG compliant alternatives to Solaris utilites, when those utilities weren't already XPG compliant. Solaris has read(sh), read(ksh), and line, but none of them has the option for a read timeout. We do have bash on our systems, but I don't know whether that's now part of the standard install.
> I'm not convinced about this; I think it has the potential to help > generate collateral spam.
How will this generate collateral spam? The daemon should just listen for SMTP connections and issue a 521 to any command save for quite. This system its self will never send any mail.
Chris Davies <chris-use...@roaima.co.uk> wrote: > Frank Slootweg <t...@ddress.is.invalid> wrote: > > If he has a UNIX system worthy of that qualification :-), he probably > > has line(1) [1] which also has a -t timeout parameter.
> > [1] line(1) is SVID*/XPG*.
> Strange. I thought Sun provided XPG compliant alternatives to Solaris > utilites, when those utilities weren't already XPG compliant. Solaris has > read(sh), read(ksh), and line, but none of them has the option for a > read timeout. We do have bash on our systems, but I don't know whether > that's now part of the standard install.
Well, I based my information on HP's HP-UX version of line(1), which is SVID 2/3 and XPG 2/3 [1], but that version being compliant does of course not neccessarily mean that the -t option is in also the SVID/XPG. So I may have spoken too soon. Sorry. I have no access to the actual SVID/XPG standards, so I can't check.
> I'm not convinced about this; I think it has the potential to help > generate collateral spam. Taylor, Grant <gtay...@riverviewtech.net> wrote: > How will this generate collateral spam? The daemon should just listen > for SMTP connections and issue a 521 to any command save for quite. This > system itself will never send any mail.
Collateral spam is defined (usually) as including DSNs from spam itself. If something tries to deliver a message to one of your servers and fails (thanks to the 521), it is required to return a DSN to the envelope sender stating the reason for non-delivery. Given that most spam forges the envelope sender, this means someone somewhere gets a message as a result of a spam that couldn't be delivered. This is collateral spam, and is considered poor practice. There are even RBLs for marking such hosts.
As I wrote originally when I offered a solution that could hang off netcat ("while :; do nc -p 25 -l -e smtp521.sh; done"), I think it has the *potential* to help generate collateral spam. This does not mean I think it will do so, but I have raised a concern for you to consider.
Chris Davies wrote: > Collateral spam is defined (usually) as including DSNs from spam > itself. If something tries to deliver a message to one of your servers > and fails (thanks to the 521), it is required to return a DSN to the > envelope sender stating the reason for non-delivery. Given that most spam > forges the envelope sender, this means someone somewhere gets a message > as a result of a spam that couldn't be delivered. This is collateral > spam, and is considered poor practice. There are even RBLs for marking > such hosts.
From the conversations that I've been part of before regarding "collateral spam" a.k.a. "Back Scatter", there is a vast difference in rejecting the message and making someone else handle the failed delivery verses accepting the message in and then later bouncing it. Seeing as how I would refuse to accept the message does not mean that I am sending any form of spam. It could be the sending site's policy to just drop messages that it could not deliver, or it could be the sites policy to send failed delivery notifications as is standard to do so. However, it is not my site that is doing the sending but rather the site that attempted to send me the message(s). If this site is taking some heat for sending too many bounce notifications, then chances are good they need to find out why they are sending too many bounce notifications and remedy the situation. Just because I'm being smarter about what messages I will and will not accept responsibility for compared to the site sending them to me does not make me a spammer.
> As I wrote originally when I offered a solution that could hang off > netcat ("while :; do nc -p 25 -l -e smtp521.sh; done"), I think it has > the *potential* to help generate collateral spam. This does not mean I > think it will do so, but I have raised a concern for you to consider.
Indeed.
However, I could liken this to me locking my doors and windows to deter a burglar. If I do so, is it my fault that the burglar went next door and went in to my neighbors unlocked house? I think not. It is my neighbors fault for not locking his / her house.
> Chris Davies <chris-use...@roaima.co.uk> wrote: > > Frank Slootweg <t...@ddress.is.invalid> wrote: > > > If he has a UNIX system worthy of that qualification :-), he probably > > > has line(1) [1] which also has a -t timeout parameter.
> > > [1] line(1) is SVID*/XPG*.
> > Strange. I thought Sun provided XPG compliant alternatives to Solaris > > utilites, when those utilities weren't already XPG compliant. Solaris has > > read(sh), read(ksh), and line, but none of them has the option for a > > read timeout. We do have bash on our systems, but I don't know whether > > that's now part of the standard install.
> Well, I based my information on HP's HP-UX version of line(1), which > is SVID 2/3 and XPG 2/3 [1], but that version being compliant does of > course not neccessarily mean that the -t option is in also the SVID/XPG. > So I may have spoken too soon. Sorry. I have no access to the actual > SVID/XPG standards, so I can't check.
Given that Solaris is an actual SysV derivative (you can find many files on a Solaris box that claim to be unpublished code of AT&T, which collaborated with Sun on the earliest Solaris) and it lacks a -t for line OR a distinct version under /usr/xpg4/, I suspect that the SVID/XPG standard does not include a -t flag.
Bill Cole <b...@scconsult.com> wrote: > In article <44e04723$0$12787$dbd4f...@news.wanadoo.nl>, > Frank Slootweg <t...@ddress.is.invalid> wrote: [deleted] > > Well, I based my information on HP's HP-UX version of line(1), which > > is SVID 2/3 and XPG 2/3 [1], but that version being compliant does of > > course not neccessarily mean that the -t option is in also the SVID/XPG. > > So I may have spoken too soon. Sorry. I have no access to the actual > > SVID/XPG standards, so I can't check.
> As warned there, line was removed from XPG4. One could argue that it is > not a standard command for *modern* Unix.
Thanks for that bit of information! The new (HP-UX 11i Version 2 September 2004) HP-UX manpage still says "This command is likely to be withdrawn from X/Open standards.", but as, as you say, it *is* removed from XPG4, your comment is very valid and my "a UNIX system worthy of that qualification" wasn't.
On Mon, 14 Aug 2006, Taylor, Grant wrote: > However, I could liken this to me locking my doors and windows to deter a > burglar. If I do so, is it my fault that the burglar went next door and went > in to my neighbors unlocked house? I think not. It is my neighbors fault > for not locking his / her house.
Wrong metaphor.
What you're doing is equivalent to filing a "return to sender" for all your postal mail with the post office. The junk mailers can then use your filing to send junk mail to someone else, and get around that other person's request for "no junk mail", by putting their intended victim as the return address of their junk mail.
-- Mark --
http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
Chris Davies <chris-use...@roaima.co.uk> writes: > On 08/10/06 06:22, Chris Davies wrote: > > I'm not convinced about this; I think it has the potential to help > > generate collateral spam.
> Taylor, Grant <gtay...@riverviewtech.net> wrote: > > How will this generate collateral spam? The daemon should just listen > > for SMTP connections and issue a 521 to any command save for quite. This > > system itself will never send any mail.
> Collateral spam is defined (usually) as including DSNs from spam > itself. If something tries to deliver a message to one of your servers > and fails (thanks to the 521), it is required to return a DSN to the > envelope sender stating the reason for non-delivery. Given that most spam > forges the envelope sender, this means someone somewhere gets a message > as a result of a spam that couldn't be delivered. This is collateral > spam, and is considered poor practice. There are even RBLs for marking > such hosts.
Actually number of DSNes is smaller when 521 is given.
If server gives 521 smtp client sends just "failed" DSN
If server do not respond smtp client sends first "delayed" DSN and then sends "failed" DSN
> What you're doing is equivalent to filing a "return to sender" for all > your postal mail with the post office. The junk mailers can then use > your filing to send junk mail to someone else, and get around that other > person's request for "no junk mail", by putting their intended victim as > the return address of their junk mail.
I'll agree that what you are saying is more correct, but not quite accurate. I am refusing to accept a message. I am not saying "Return to sender". It is the post office that is choosing to return the message to the sender.
Before you say that the post office does not have the ability to filter messages, I'll cut you off at the path. Mail servers have the option to be selective about what messages they do pass, and thus they have the option to filter and hold people accountable for what they send.
Also keep in mind that email was designed and is primarily intended to be sent between two servers, the sending parties server and the receiving parties server. In this scenario the sending parties server will (or should) have fine grained control over what messages it will accept from senders. Thus if the receiving server server refuses to accept a message the sending server will have a very good idea who to send the message back to.
IMHO the ideal solution would be to either filter during message submission or directly there after. I'm saying during submission or directly there after because there are some lame MUAs out there that will not return the an error message back to users when they try to send, much less the correct one. In this case the error can be sent as a DSN that people will much more likely be able to read (if they will or not is another story) where as the MUA may hide the real error.
In this type of scenario it is extremely likely that the error message will reach the correct recipient. About the only other thing that comes to mind regarding this would be to set up some sort of who is allowed to send as who in conjunction with authenticated senders.
<chris-use...@roaima.co.uk> wrote: >Collateral spam is defined (usually) as including DSNs from spam >itself. If something tries to deliver a message to one of your servers >and fails (thanks to the 521), it is required to return a DSN to the >envelope sender stating the reason for non-delivery. Given that most spam >forges the envelope sender, this means someone somewhere gets a message >as a result of a spam that couldn't be delivered. This is collateral >spam, and is considered poor practice. There are even RBLs for marking >such hosts.
1.) If someone is trying to deliver email to his "server", and they would send a bounce for "message refused", they're also eventually going to send a bounce for "can't connect to server, I give up".
2.) No one legit will be trying to deliver email to his fake server.
3.) Most spam is sent via spam zombies. Spam zombies don't send DSNs when their email is refused.
Steve Baker writes: > On Mon, 14 Aug 2006 10:41:27 +0100, Chris Davies > <chris-use...@roaima.co.uk> wrote:
>>Collateral spam is defined (usually) as including DSNs from spam >>itself. If something tries to deliver a message to one of your servers >>and fails (thanks to the 521), it is required to return a DSN to the >>envelope sender stating the reason for non-delivery. Given that most spam >>forges the envelope sender, this means someone somewhere gets a message >>as a result of a spam that couldn't be delivered. This is collateral >>spam, and is considered poor practice. There are even RBLs for marking >>such hosts.
> 1.) If someone is trying to deliver email to his "server", and they would > send a bounce for "message refused", they're also eventually going to > send a bounce for "can't connect to server, I give up".
> 2.) No one legit will be trying to deliver email to his fake server.
> 3.) Most spam is sent via spam zombies. Spam zombies don't send DSNs when > their email is refused.
Furthermore, and if someone does send the DSN, it's not going to be my server, it's going to be the server trying to unload the spam on me. That server is the one who's going to get blacklisted due to spam backscatter, and not me.
>> On Mon, 14 Aug 2006 10:41:27 +0100, Chris Davies >> <chris-use...@roaima.co.uk> wrote:
>>>Collateral spam is defined (usually) as including DSNs from spam >>>itself. If something tries to deliver a message to one of your servers >>>and fails (thanks to the 521), it is required to return a DSN to the >>>envelope sender stating the reason for non-delivery. Given that most spam >>>forges the envelope sender, this means someone somewhere gets a message >>>as a result of a spam that couldn't be delivered. This is collateral >>>spam, and is considered poor practice. There are even RBLs for marking >>>such hosts.
>> 1.) If someone is trying to deliver email to his "server", and they would >> send a bounce for "message refused", they're also eventually going to >> send a bounce for "can't connect to server, I give up".
>> 2.) No one legit will be trying to deliver email to his fake server.
>> 3.) Most spam is sent via spam zombies. Spam zombies don't send DSNs when >> their email is refused.
>Furthermore, and if someone does send the DSN, it's not going to be my >server, it's going to be the server trying to unload the spam on me. That >server is the one who's going to get blacklisted due to spam backscatter, >and not me.
And furtherfurthermore, the amount of DSNs generated due to a server replying 521 to everything will certainly be no more than that generated due to that same server replying 550 to one or more RCPT commands - and the DSNs (if any) will in both cases be generated at the same place. Hopefully the Holy War on Spam has not yet reached the point where we're not allowed to reject invalid recipients in the SMTP dialogue for fear of creating "backscatter" somewhere...
> And furtherfurthermore, the amount of DSNs generated due to a server > replying 521 to everything will certainly be no more than that generated > due to that same server replying 550 to one or more RCPT commands - and > the DSNs (if any) will in both cases be generated at the same place.
Indeed.
> Hopefully the Holy War on Spam has not yet reached the point where we're > not allowed to reject invalid recipients in the SMTP dialogue for fear > of creating "backscatter" somewhere...
I do not think that this will be a long lived belief if it ever does get to that point. The idea here is to chase the rejection point back to where the message originated.
It would be interesting to set up servers to require authentication to send and then only allow each authenticated user to send messages as a very small subset of users, namely the authenticated user and null reverse path. I believe such accountability offered by such a system will help eliminate a LOT of spam. Of course, it would have to be very easy for someone to call their ISP and say, "Hay, I'd like to send emails out as this user, please add it to my list of allowed sending addresses.". You may even be able to allow such a thing to be done based on a web form.
"Taylor, Grant" <gtay...@riverviewtech.net> writes: > It would be interesting to set up servers to require authentication to > send and then only allow each authenticated user to send messages as a > very small subset of users, namely the authenticated user and null > reverse path. I believe such accountability offered by such a system > will help eliminate a LOT of spam. Of course, it would have to be > very easy for someone to call their ISP and say, "Hay, I'd like to > send emails out as this user, please add it to my list of allowed > sending addresses.". You may even be able to allow such a thing to be > done based on a web form.
Problem is that authentication do not scale beyond initial submission of mail.
Authentication is often used between MUA -> smtp (submission) server
but between next(?) step it is no longer practical
MTA (isp 1) -> MTA (isp 2)
RFC 2554 SMTP Service Extension for Authentication is published at March 1999
This specification itself allow that kind usage. After smtp server is accepted authentication of smtp client, there is passed authenticated user of mail separately on MAIL command.
| 5. The AUTH parameter to the MAIL FROM command | | AUTH=addr-spec | | Arguments: | An addr-spec containing the identity which submitted the message | to the delivery system, or the two character sequence "<>" | indicating such an identity is unknown or insufficiently | authenticated. To comply with the restrictions imposed on ESMTP | parameters, the addr-spec is encoded inside an xtext. The syntax | of an xtext is described in section 5 of [ESMTP-DSN]. | | Discussion: | The optional AUTH parameter to the MAIL FROM command allows | cooperating agents in a trusted environment to communicate the | authentication of individual messages. <...> | | Examples: | C: MAIL FROM:<e=...@example.com> AUTH=e+3D...@example.com | S: 250 OK
Problem is expansion of a trusted environment which do not scale.
