Has there been any discussions about "When" spammers can be allow to send
mail?
If so, never mind.
If not......
I was wondering it makes any sense to include a concept describing receiving
server "Allowable Hours." for accepting mail.
A client can use this target server information to help schedule mail/spam
activities, thus respecting server loading issues, i.e, day vs. night
operations.
This can be added ion any of extended DNS records proposal
TXT="Hours.Open=03-06 GMT" ; no domain, return path validation
performed
TXT="Hours.Open.Secret=123FX23" ; password to be used for
compliance
TXT="Hours.Closed=08-05 GMT" ; normal business hours for
established relationships
TXT="Hours.Closed.secret=232r223" ; password to be used for
compliance
The above are just an examples for illustrative purposes. I'm sure the
attributes can be reduced.
The compliant client will obtain the secret password to be used with an
extended EHLO command. Nothing secured about it. The client simply needs
to echo it with a new EHLO extension keyword:
C: EHLO clientdomain
S: 250- SECRET
S 250 Help
C: SECRET 123FX23
possible response codes:
S: 250 - Ok, continue
S: 452 - Sorry, wrong secret, try again
S: 552 - Sorry, wrong hours, don't try again during closed hours
The server can choose to change the secret every hour or daily or whatever.
Its a simple method to make sure the client is compliant within the hours
system.
If a non-compliant client (does not issue the SECRET) connects during open
hours, normal SMTP operational system policies apply.
If a non-compliant client connects during closed hours, restriction,
validation concepts may apply.
In Mr. Malamud's No Soliciting proposal
http://www.ietf.org/internet-drafts/draft-malamud-no-soliciting-02.txt
He can add a similar concept to the EHLO response. The compliant client can
then quickly see when the system is open. However, this method would be
redundant since a compliant client would need to be changed anyway. Might
was well get the info from DNS if already compliant. The client can then
avoid connecting to the server during non-solicitation hours.
Benefits:
- organizations would be able to reduce servers load during their main
day/hours.
- Scalability and/or overhead, redundancy issues with some of the proposals
would be reduced since it would only be active during certain times of the
day.
- compliant clients (hence spammers) would now have the incentive to follow
the protocol because it will help get their foot into the door in the future
new "controlled" smtp environment. They now know they would be able to
push mail during certain hours only.
Cons:
- Possibly concentrated bandwidth issues. If highly honored by spammers, it
might result in periods during the day/night where network activities would
be high. I guess this might be controlled with additional
"hours.mail.limits" attributes.
- Requires software change (or usage of a smtp proxy)
The old Fidonet Network has a similar concept called global Zone Hour which
allowed for unsolicited contact by any member in the network. The main goal
was to guarantee network contact even for those systems who did not allow
direct p2p during non-zone hours. Zone Mail was the only thing allowed
during this period (No file attachments).
Comments? Is it worth any more consideration?
Hector Santos
http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg